While you’ve been worrying about your BDD adverbs the iFart dev just made $40,000.
Can you give 140 char synopsis of "opportunity cost of TDD?"
Is #TDD always a "Best Practice"? Is there even any such thing? When shouldn't you use it? What could you do instead?
Testing implementation is terrible terrible terrible.
The pendulum is swinging back and forth in the TDD and developer-testing world...
I blogged over two years ago about Testing Backlash and then again one year ago Are you too agile for TDD/BDD?
It seems the time has come for the pendulum to swing by once again. In an almost mystical conjunction a lot of alpha geeks are voicing current "new" insights about automated testing and TDD. Maybe this is the developer community climbing the ladder to another stage of competence or to another stage of grief (the viewpoint is probably depending of the pains in your current project)… but maybe it is just that alpha-geeks like any other intelligent beings are getting bored after a while and turn to new topics.
Anyways, here is a list of the recent tide of "let's rethink automated testing":
- Michael Feathers: Taking Automated Tests Off The Pedestal
- DHH: Testing like the TSA
- Scott Bellware: The Inflection Point - How Long can you Safely Avoid Automated Testing
- Alberto Gutierrez: The evil unit test.
- Dan North: The Art of Misdirection: The opportunity cost of TDD (or in the NDC Magazine)
Just for completion I am reenumerating older reflections on the topic:
- The Dark Side Beckons? by Obie Fernandez
- Test-Driven Development and Embracing Failure by Steve Freeman
- Problems with TDD an Essay by Andrew Dalke. Heavily discussed on his blog and on Hacker News.
- Ayende's posts: Even tests has got to justify themselves and re: Are you smart enough to do without TDD
- And finally Luce Francis brilliant presentation: Testing is Overrated (matching blog post, slides)
Update:
Tudor shows in When testing does not cut it that testing is not always the best alternative to ensure certain properties of a software system.
