Over the many years I’ve been practicing TDD, I’ve sought to incorporate new learning about what appears to work best. If you were to look at my tests and code from 1999, you’d note dramatic differences in their structure. You might glean that my underlying philosophy had changed.
Yet my TDD practice in 2012 is still TDD. I write a test first, I get it to pass, I clean up the code. The core goal of sustaining low-cost maintenance over time remains, and I still attain this goal by crafting high quality code–TDD gives me that opportunity.
TDD is the same, but I believe that new techniques and concepts I’ve learned in the interim are helping me get better. My bag of TDD “tricks” acquired over a dozen years includes:
-
Promoting more cohesive tests (i.e. tests that demonstrate and document a single behavior)
-
Using BDD to have a more holistic focus when doing TDD, which in turn promotes improved naming and test structure
-
Emphasis on programming by intention in tests (including writing assertions first sometimes)
-
Using mocks to explore design
-
Practicing TDD katas
-
Emphasizing improved abstraction levels in tests, to help clarify test intent for future readers
-
Thinking about the simplest possible transformation as the best candidate for the next test
-
Using better mock tools that emphasize clarity and simplicity
There is of course no hard data to back up the claims that any of these slightly-more-modern approaches to TDD are better. Don’t let that stop you–if you waited for studies and research to proceed, you’d never code much of anything. The beauty of TDD is that its rapid cycles afford many opportunities to see what works best for you and your team.
(But remember: You only really know how good your tests and code are when others must maintain them down the road.)
Should you push more in the direction of one assert per test? Is Given-When-Then superior to Arrange-Act-Assert? Those are entertaining things to debate, but you’re better off finding out for yourself what works best for your team. Also, be willing to accept that others might have an even better approach.
I recommend investigating all of the above ideas and more–keep your eyes open! Just don’t get hung up on any one or assume it’s the One True Way. The practice of TDD is a continual voyage of exploration, discovery, and adaptation.
