[ original gist 4 Aug 2013 ~ short reply on LinkedIn, copied for posterity… ]
TDD for integration tests? YES, but for different reasons than “maintenance” or
In testing, there is test creation and test maintenance. You have to do both if
you want tests to serve you well. Same for any product or tool.
But if maintaining tests slows you down ~ that is, the product requirements change
so rapidly that keeping tests AND product up to date is a strain ~ then they are
over-designed beyond what you need, and that’s because your product is not well
You can create an integration test ~ TDD style ~ from the requirements as you
and the team understand them. Such tests don’t need to be comprehensive, more
like sanity checks. Just one or two of these per iteration is enough to surface
the critical misunderstandings early. Then you can integrate the useful parts
into the larger suite.
Same goes for unit tests ~ though in TDD fashion, you lean on them more heavily
to get at fundamentals (design patterns, mocking, speed, etc.). Bigger tests
mean a story’s implications are not well understood ~ “it will take more effort”
is the correct issue when you see this happening ~ “we need to refactor this into
smaller parts” is another correct response.
The goal is not the test suite but a well understood product you can maintain ~
and maintain pace without burning out.