Automated Acceptance Tests are not worth the cost

InfoQ cites Jim Shore (author of The Art of Agile Development), who in has abandoned Automated Acceptance tools because they're not worth the cost, as he reported in February, in response to a question from Gojko Adzic. This was followed up by Jim Shore with a summary of Alternatives to Acceptance Testing, and a twitter debate about Fit recorded and commented on by Eric Lefevre.
So, everyone re-emphasizes that getting business folks together with developers and having them talk through examples is still a must-do, whew. But regarding automating these examples, Shore, Rainsberger, and Marick say no. Others argue yes. -- An interesting debate indeed. What say you? -- InfoQ
So, I'm not in application development, I've only recently arrived at Agile via the #devops movement, and I've been gathering many references to things I learned about in Gent.

What strikes me is that Jim Shore does not say no to automated testing. Number one in his list of alternatives is still his 'defect-elimination workhorse' of Test-Driven Development (TDD).

And that number one actually consists of three seperate practices: unit test, focused integration tests, and end-to-end integration tests.

Those are all part of the Continuous Integration paradigm: ship early, ship often. And all of these tests are essential for such practices as refactoring. (Or we will never be able to fulfill one primary requirement for the latter: unchanged behaviour).

Automated builds and automated testing are all about keeping the feedback loop short.

Acceptance tests come down to one simple thing, or just one single word...


Q42 Techops - devops reinvented, or parallel evolution?

A foaf (actually, more the soaf - son-of-a-friend) just started his new job at q42, a young team of programmers building solutions focused more on the user than on the customer.

All employees (except the office manager and general manager) are interaction engineers, with a passion for all aspects of web development.

And q42 has no separate IT department or System Administrators...