How do test-driven development and Agile development most effectively combine or overlap?
Fair question. A large number of folks look at ideas like these as completely independent of each other and I’m not entirely certain why. A simplified view of test-driven development (TDD) is to develop a test, execute the test, write the code so the test passes and repeat. And the good part? The code works at the end of each cycle.
At the end of each Agile iteration, you should also have executable code that will address at least one -business need.
How do they combine or overlap? Simply put, teamwork, cooperation and communication. We need to keep communication open, help each other out and realize that we are looking at the same block of code or functions from different angles.
Testers can still execute tests as they would for any code that gets developed. Ideally, the code developed through TDD will have fewer code related problems when the testers start working on it simply because the developers have aggressively unit tested it through their own testing. This does not change because the context of the environment changes.
The issue seems to boil down to the interactions between team members. Having said that, isn’t that the point of most approaches to Agile development? The more the team works together, the more they communicate, share information and insights, the better the software product is likely to be?
How this is done will vary based on each team’s structure, organization and needs. Broadly stated, people need to work together to deliver the best software product they can. This is not unique to Agile or TDD or any other development approach. It is, however, one of the great obstacles in all of them.
This was first published in June 2012