How feasible is to use TDD in Agile Development with shorter iteration schedules on development road. Are there any best practices to follow. I know google will yield tons of results but I want to hear from experts in the forum.
It's feasible. If you consider that TDD is a technique for "how you build quality software," and not a separate activity, then the iteration length doesn't impact the ability to incorporate it.
Done well, introducing TDD into a short-iteration project can be one of the key things that helps keep sanity, since things are changing so rapidly. Otherwise, it's highly likely that your code will turn into an unrefactored mess in short order.
Let's see, downsides? I would hope that enough developers on the team had decent TDD experience before there were any high expectations about the amount of test-driven that they would produce in a short iteration. But this is the case with any new techniques. Shorter iterations will only exacerbate things that you aren't doing well.
Another downside is that it's hard. I'm a firm believer, but I still get stuck in spots where I can't quite see how to test first and I just blunder away. It has a significant learning or adaptation curve, and it requires excellent discipline. If you drop into a team that already has the habit and support it would probably be easy, but I can't claim to have mastered it on my own.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Joined: Oct 31, 2000
Exactly. One needs to have solid discipline. What happens with Test first approach is one has to refactor test cases very often in shorter iteration schedule. With new requirements coming-in every day or so, one has to change design first and then test cases and then implementation. So, we're adding a new layer (TDD) in this development life cycle. But I know TDD pays off over the time. I firmly believe that base for TDD is UnitTesting otherwise you can't even dream about TDD. TDD and Cruise Control are secret ingredients of Agile development... I would like to hear from people who are already implementing TDD in companies.
What happens with Test first approach is one has to refactor test cases very often in shorter iteration schedule. With new requirements coming-in every day or so, one has to change design first and then test cases and then implementation.
Why do we need to change design first? After all, the test cases combined with the implementation are the design. The real design. The only design that actually, concretely exists. Everything else is vision and speculation, an abstraction of what's in the code.
There's no way around having to think before doing. If that's what you mean by changing the design, well, you'll just have to accept that thinking is an essential part of what we do. No method, technique or process is a substitute for thinking.
Now, if we accept this then what remains as the argument is that we need to frequently change the tests and then change the production code.
Now here's a question. Why do we need to refactor test cases very often? Is it because the test cases are too large? Is it because our tests are too intimate with the objects they're testing? Why is that? Could it be an issue with our design not being as testable as it could be?
Furthermore, why do we mentally separate our tests from production code? After all, aren't the tests, combined with the implementation simply a definition of the system? Should we be simply talking about "the code" rather than "tests and code"?