0

How Test Driven Development can pretend to be Agile? To do Test Driven Development you need to write your test first. Then you need to know your methods, your business and your scenario before coding. Actually you need a full business and technical analyze of your software. You are definitively not agile.

And what about refactoring? How wan I refactor my tests or unit tests before my code. Each time I want to refactor or change something in my code I need to adapt first my tests. It's not really Agile. It's too heavy to be Agile. Eventually you can say than with testing you are Agile but you are even more Agile without testing.

3

Actually you need a full business and technical analyze of your software.

Your assumption is wrong: actually you only need a good enough business and technical analysis. That's how you can still be agile (with or without TDD).

At any rate, TDD works on a lower level than the full system. When working in TDD fashion, you are focusing on a single task / story, not the whole system. You need to have a good enough understanding of that single story to get you started. And of course, the story requires some context to make sense. But that some context is usually much less than what a full business and technical analyses encompasses.

Before starting to work on the product backlog, the Product Owner (if necessary) gives the team an overview of the system, the team members ask questions and discuss them to gain a good enough common understanding of the purpose of the system, its users, the way it is (going to be) used etc. Then they start breaking down stories into manageable backlog items and working on the product backlog. Again they discuss each backlog item / story to get a common understanding on what it means, how it fits into the big picture etc. Once the team members get a good enough understanding of an item to estimate its relative size, they estimate it, then move on to the next PB item.

When an item is selected into the next sprint, again the team discusses it in detail enough to understand what tasks need to be done in order to complete the item. This gives them a good enough understanding to start working on individual tasks in TDD fashion. If, during work, a team member finds an unclear spot or needs more information or clarification, s/he discusses the issue with the PO. This way, the team has the needed information, and only that, just when they need it, to define their test cases and interfaces, then implement them in TDD fashion.

  • And what about refactoring? How wan I refactor my tests or unit tests before my code. Each time I want to refactor or change something in my code I need to adapt first my test. It's not really Agile. It's too heavy to be Agile. – Bastien Vandamme Jul 29 '14 at 9:02
  • If you test interfaces rather than concrete classes, you don't need to change your tests every time you change the implementation. Sure, unit tests do require maintenance of their own, which may be seen as an "overhead" to the implementation process. However, the overhead of manually testing each change is much bigger. Just it is easy to overlook it, or not count it in to the costs of development. Or simply fail to do the tests properly, letting bugs slip through, which of course result in even more extra work and disruption in the long run. Is that more Agile? – Péter Török Jul 29 '14 at 9:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.