Nice article. I’m also a big fan of Acceptance Test-driven development. If anyone is interested in ATDD for web apps, they should check out Helium (http://heliumhq.com). (I’m one of the cofounders). It lets you write executable test scripts of the form

startChrome();

goTo(“Google.com”);

write(“Helium”);

press(ENTER);

click(“Helium – Wikipedia”);

assert Text(“Helium is the second lightest element”).exists();

This is Java, Python bindings are also available. Note how no reference to any HTML source code properties is required (thus the tests can be written in a TDD style, before the implementation).

I should also point out that Helium is a commercial product, so you (/ your company) has to pay to use it.

Does your product provide proper page objects? The way it's used in the examples (where the test specifies the direct page interactions) will quickly create difficult to maintain code. For example, http://canvascode.wordpress.com/2013/11/20/maintainable-auto...

Good question. The answer is no. You still need to write the page objects yourself. But it's much easier. Compare

driver.findElement(By.xpath("//input[@type='text' and @value='First Name']");

with

TextField("First Name");

Helium makes it much easier to identify the elements of the PageObject.

I just recommend instead using a custom data- attribute to identify your elements so you don't rely either on text, HTML structure, or CSS classes since all of those can change but may not affect functionality therefore should not break your test.

I ended up writing a Selenium-IDE plugin for a similar thing with hierarchical "data-test-label" attributes, since our test-team seemed unwilling to actually learn XPath, and the default Selenium-IDE output was far too hyper-specific and brittle.

Ugly but standards-following output:

        xpath=(((
        //.[@data-test-label='foo'])[1]
        //.[@data-test-label='bar'])[1]
        //.[@data-test-label='baz'])[1]
        /a

This defines a three-step search which skips over a lot of probably-unimportant tags.

That's surely a good solution. It requires write access to the source code of the web application being automated though.

That's not to say that Helium is a silver bullet. It certainly always depends on the context. For instance, I know of a bank here in Austria that generates a lot of the Java source code for their internet banking app from an abstract model. They also generate page object code immediately from this abstract model, which is therefore always up to date and precise. This is one example where I would say using Helium would probably not pay off.

There's a slightly different take on this that was presented last year at RailsConf

http://confreaks.com/videos/2448-railsconf2013-of-buyers-and...

tl;dr: Different kinds of technical debt have different interest rates. Paying loan shark or credit card rates for a long time is bad. Paying mortgage rates is fine. Not having any technical debt means you over payed up-front.

That's probably about as true as saying "not having any financial debt means you overpayed up-front" -- which is to say, yes, it's possible there's an opportunity cost which means you don't make an economic profit. But it seems to me this isn't always legible, and beyond that it's difficult to think of any situation in which it's more expensive to pay up front if you have the option.

A lot of times you don't have the option because your resources at hand are scarce compared to what you need/want to buy, so debt is part of the calculus of allocating your current and (hopefully) future resources. And that's fine. It seems to me that's different from saying "no debt means you overpaid up front."

Plus, that sounds like the kind of thing non-technical management might deploy to neutralize discussion without having to engage with the issues at hand.

It's troubling to hear sentiments like that. Statements like "no debt means you overpaid up front" have a nasty habit of being repeated by people as after-the-fact rationalization for their own failure to design. It is anti-intellectual: it reflects a culture where writing code is valued over understanding the problem. It also devalues our time to non-technical management.

Over-design is a legitimate concern. But, if you don't know much design, however, you probably aren't going to fall into this trap. You're more liable to under-design things.

If you over-engineer today and then fail tomorrow you'll lose a lot more out of pocket. If you build an MVP and then fail you'll lose a lot less. In the over-engineering scenario you will essentially have "overpaid upfront" when you do fail. The amount overpaid is relative to what you could have paid.

This strikes me as being a different problem that needs a different metaphor -- overbuying up front rather than overpaying. Or, as people sometimes say, scope creep.

Not having any financial debt means you probably have rich parents. That sounds like overpaying up-front to me.

These graphs are almost identical to the graphs of all too many Java generational garbage collection cycles I have seen in my life. Eden is the stupid stuff you do when figuring stuff out that hopefully never makes it into a commit unless shit gets crazy, survivor space makes it into a commit and maybe a release but hopefully gets cleaned up quickly, then once in a while you have a cleanup of the tenured generation.

This is when you eventually come back and do some bigger refactoring and cleanup to drop back down before you hit your ceiling. But you have to decide if you want to stop all other development while you do this, or if you can be smart and pull off tricks to coordinate doing the work while stuff still happens and/or parallelize it without having too much overhead. All without really knowing for sure where the ceiling is because other stuff is going on outside of your JVM.

If your major GCs can't successfully clean up your survivor space then you end up caught in a loop of endless GC attempts without making progress, looking for anything you can clean up or refactor to reduce TDD, with very little success. You start wondering if it is even possible or if you should just SIGKILL it all and start over.

Sadly, the TDD side of it doesn't fit into this analogy ... at least not yet. You could definitely work the dark side of TDD into this though... brittle, inflexible poorly factored tests that are in and of themselves technical debt and take up valuable memory you could be using to scrape by.

Yep. Technical debt analogises to financial debt quite well. It's not as fungible, but similarly you can fall into debt, take on debt in a planned way, discover you're not as clever at managing it as you thought you were, etc.

I also highly recommend Denise from Dreamwidth's famous post on the subject, which is a great intro to the concept for not-so-technical people as well (it was written to explain to the user base what they'd been doing): http://denise.dreamwidth.org/57248.html

> All this begs the questions “yes, but How?”.

No, it raises the question.

Otherwise, a great article.