TDD in a two-week sprint? Practical?

Question

On one hand, it may take a while (or a long time) to create and run tests with TDD. The worst case scenario is when the test cases fail and the entire program fails. Refactoring may take longer than expected, and there isn't much time when it comes to a two-week sprint.

On the other hand, I heard smaller groups benefit from TDD. It is easier to develop test cases. Refactoring can be simpler too. Well, TDD is beneficial because a 100% working, bug-free program is what we, developers, ultimately desire.

Suppose a small project is reasonable enough to complete in time during a two-week sprint. Is it ideal or practical to use TDD when it comes to small groups and projects? Or should the small group adhere to Agile development?

Answer 1

I started TDD on such a small project, so certainly it IS possible.

Limiting factor is not length of a project but how much "plumbing" you need to develop to get your tests going. But if you make decision to use unit tests, you cannot save time by not writing the test - so you may as well to start by writing (failing) unit tests. You will be surprised how your API design will be influenced by need to test it.

Even better if you can use similar 'plumbing" for multiple projects, so you can reuse the plumbing. You always need to customize it a bit to your environment, set it up etc.

Answer 2

Projects of any size will benefit from TDD. TDD and good test-suites makes sure you can restructure your code when it needs change for a new feature. This will allow you to go faster, because you have the confidence to refactor the structure to fit the new ideas. Something most developers do not dare without tests. Not refactoring often leads to more hacks, complexity, dependencies, fragility and slowdowns.

But to go faster with TDD you need practise. It is a skill and just like all other skills you need to learn it well to go fast with it. For developers that are new to the concept this learning curve can be pretty high. Learning it well can take weeks if not months, be sure to include someone with good TDD skills in your project if you want to scale.

We have some teams that do everything TDD and who execute sprints of a single week. Don't see how two weeks would differ. Stories should be 1-3 days in size anyways.