File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Agile and Other Processes and the fly likes TDD in Agile Development Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "TDD in Agile Development" Watch "TDD in Agile Development" New topic
Author

TDD in Agile Development

Anil Vupputuri
Ranch Hand

Joined: Oct 31, 2000
Posts: 527
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.

Thanks.


SCJP 1.5, SCEA, ICED (287,484,486)
Jeff Langr
author
Ranch Hand

Joined: May 14, 2003
Posts: 762
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.

Jeff


Books: Agile Java, Modern C++ Programming with TDD, Essential Java Style, Agile in a Flash. Contributor, Clean Code.
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
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
Anil Vupputuri
Ranch Hand

Joined: Oct 31, 2000
Posts: 527
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 Unit Testing 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.
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
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"?


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: TDD in Agile Development