automated tests aren’t testing

This article serves as the guide post to a series of focused, practical writings about TDD. Included, I hope, are some counter-intuitive and extremely helpful observations for those who have found themselves deep in the TDD world, have perhaps started to wonder about some of its quirks, and are wondering if there are other people who have some of those same questions.

In the course of reading this you may begin to wonder if I’ve even read Kent Beck’s “Test Driven Development: By Example”. I assure that I read it near its publication date back in 2002, have been practicing TDD ever since, and still recommend this book. However, none of that makes TDD any less problematic, or any less useful.

Here is the basic outline of where we’re headed over the next several posts. In this list where I say “tests are …” or “tests aren’t …”, I’m referring to automated tests that you run as part of a test suite.

• tests aren’t testing
• tests do not prove correct function
• tests won’t tell you whether your code is any good
• tests make it harder to change code — by design
• tests will not help you design software systems
• units tests, pound-for-pound, are superior to higher-level tests
• I’ve given up on the test-first strategy
• Cucumber is a special kind of hell that deserves to be thrown on the trash heap of failed technology