Can you be Agile without doing TDD (test driven development)?

Question

Is is possible to correctly call yourself (or your team) "Agile" if you don't do TDD (Test-Driven Development)?

Answer 1

Yes, yes, yes, a million times yes.

Agile is a philosophy, TDD is a specific methodology.

If I wanted to be really picky I could simply point out that there are quite a few variations of xDD - which their advocates will explain in depth are not TDD - but those are still substantially bound up with test first so that would be cheating.

So lets says this - you can be agile without doing "test first" development (look at the way scrum works - nowhere in there are there specifics about how you write code). Look at a kanban board, look at all sorts of agile methodologies.

Do you want unit tests? Of course you do, for all kinds of reasons - and you might well make an argument that you can't be agile without unit tests (although I suspect that you can be) - but you don't have to write them first to be agile.

And finally, its equally true that you could do Test First without being Agile and strong arguments for doing test first regardless of your overall dev philosophy.

---

It seems that others (with a more SOLID rep) have a similar opinion...

http://www.twitter.com/unclebobmartin/status/208621409663070208

@unclebobmartin: http://t.co/huxAP5cS Though it's not impossible to do Agile without TDD and OOD, it is difficult. Without TDD the iteration rate of...

(The link in the tweet is to the full answer on LinkedIn)

Answer 2

"Being agile" simply means adhering to the values and principles of the agile manifesto. Nothing in that document mentions TDD, or even unit testing for that matter.

So yes, you can be agile without doing TDD or unit testing.

I wouldn't recommend it though...

Answer 3

Yes,

Look at one of the agile values:

Individuals and interactions over processes and tools

That should answer it already. TDD is a certain methodology, a process. Indeed a process that could possibly be used in agile development processes, but nothing more. I think that maybe TDD is state of the art now when being agile. But I think that the concept of agile will still be able to last, even if maybe TDD has been replaced by other practices.

I would sum it up like:

• Today TDD is a defacto-standard for being agile

• There can be ways of being agile without TDD

Answer 4

I say

No [sort of]

If you go back to the original source http://en.wikipedia.org/wiki/Extreme_Programming TDD is fundamental to the process; the tests replace the requirements specifications and use-cases of waterfall, serve as living documentation and functioning examples, etc. They're indispensible.

However, there's so many different flavors of 'agile' floating around now that it's entirely possible that one of them eschews TDD

EDIT: @Murph's interpretation of the question seems to be the preferred one. Heck I even upvoted it, it's a good answer. However, I maintain my position that the Agile Manifesto is a set of principles, not a development methodology. I see no use in saying "oh yes I'm agile" without actually implementing the practices that bring the benefits. In particular:

Working software is the primary measure of progress.

and

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

To me, these two principles imply if not require TDD - at least I know of no other way to achieve them without it!

EDIT 2: yes, technically you can write the tests afterwards; but I still regard test-first/TDD as fundamental. Not because you can't "be agile" without it, but because you will be more agile with it. Test-first/test-driven is a far more efficient approach than test-later/test-afterthought. The test descriptions are the requirements. Don't put them off until later ;-)

EDIT 3: I finally figured out what bothers me so much about Murph's very well-written answer. It's that notion that one could "be Agile" without actually doing it. And "doing it" (as shown above) pretty much requires TDD.

Answer 5

Strictly, you are agile by adhering to the agile manifesto. In practice, a code-base isn't agile unless it has good test coverage. You can do TDD and write the tests before/during the development of functionality or write tests for the functionality after it's developed. It's usually easier and more effective to do it the TDD way though.

Answer 6

You can be agile, but there is probably room for improvement.

One of the principles in agile is that you must be able to respond to change. This means that do not know in advance what you have to build. If you were following a waterfall process, you would know x months in advance exactly what you need to build, and you could design individual software components so they each take part in some larger scheme, reaching the final product (at least you would think that it was so). But since agile dictates that you don't know what the final product is, you never know what you code will be used for, and more importantly, when it will be changed.

Therefore you require a thorough test suite to make sure that the features that you have already build continues to work as the code base is modified.

But that itself is not TDD. If you write the tests after you write the code, it is not TDD. But TDD helps with another aspect, it prevents overproduction.

In my own agile team I have been struggling with developers writing code that they believe would become useful later in the project. Had that been waterfall development that would probably be OK, because they were adding support for something in the project plan for the next x months.

But if you are following the agile principles you should not write this code, because you have no idea if that will even be necessary. The feature that was planned for next week can suddenly be postponed indefinately.

If you correctly follow the TDD principle, then a single line of code cannot exist before a test dictates this line of code (personally I can write some trivial code without testing), and if you start by writing the acceptance test, then you only implement exactly what is needed to deliver the required features.

So TDD helps avoiding overproduction, allowing the team to be as effective as possible, which is also a core agile principle.

Working software is the primary measure of progress

Answer 7

Can you be Agile without doing TDD (test driven development)?

Short answer: Yes.

Longer answer: There are a lot of really good answers already to this question and very good references. I will not try to debate those points.

In my experience, Agile is about picking the right level of Lean-ness for the project at hand. What do I mean by Lean-ness? And, why do I bring it into this answer?

Lean does not mean chopping everything possible out of your method. As one of our colleagues noted, you do not have to include TDD or Unit Test into your behaviors. However, in the project context you find yourself, it may or may not be beneficial.

Let's think about the supply chain for a large unnamed retailer located in AK. There is the consumer. They go into the store. The store receives various products via truck. The trucks, presumably, get those products from a warehouse. The warehouse is filled by shipments from various manufacturers. The manufacturers in turn have whole chains of supply themselves.

What happens when the general manager for shipping in the above supply chain is told that he will get a $1 million annual bonus for every year that he has less than 10 trucks in the fleet? He will immediate chop the fleet to 9 trucks. In this "awful" scenario, this will drive up the amount of goods stored in the warehouse (driving up cost in that node). And, it will "starve" the store fronts.

So, the overall supply chain suffers if local optimization is allowed without consideration of the whole.

Back to TDD and UT. TDD is a requirements expression mechanism. The system MUST perform to those constraints. Fair enough. TDD can replace Use Case Drive Development's requirements behavior or User Story Driven Development's requirements behavior. It has the "leaning" benefit of combining the Unit Test and Requirements work loads. It is a benefit if the overall work load is reduced. It is not, if the overall supply chain's work load is increased (let's fix quality).

And so, you asked: Can you be Agile without doing TDD (test driven development)?

Sure you can. A different, and perhaps better, question is: -- If I apply TDD to this project, will it result in an overall more efficient delivery of software or a less efficient?

To quote a favorite author... J.R.R. Tolkien

Lord of the Rings. Fellowship of the Rings. Pg 94 'And it is also said', answered Frodo, 'Go not to the elves for counsel, for they will both no and yes.'

So, in the end, ... it depends. You must answer the question. Which path will most efficiently lead you to your desired goal(s).

To TDD or not to TDD. That remains the question. :-)

PS - I am reposting this answer on another site too. https://www.ibm.com/developerworks/mydeveloperworks/blogs/c914709e-8097-4537-92ef-8982fc416138/?maxresults=15&sortby=4&lang=en

Answer 8

Comparing to engineering a castle.

Agile Castle

If you were to engineer a castle using Agile. You'd write portions that have specific functions and encourage the user to use the functional parts, adjusting future design to the reactions of the user. So, you build the dungeon, and communicate with the dungeon keeper, you'd test the foundation provided by the land and the dungeon. You'd build the parapets and ask the nightwatchmen if it's good. You'd build the walls and have the soldiers test the defensive value. You'd build the kitchen and have the cooks look it over. And during this process, every part to date would function in addition to the current structure. So when you finished the dungeon, you could move the prisoners in. And so on. But when you've finally finished the castle, you find out the prisoners escaped. Now you need to go back into the dungeon and find out that you need thicker bars, but the doors aren't deep enough to hold the bars, and the hinges don't support bigger doors.

TDD Castle

With TDD, you show up with the prisoners, and see if they escape. Then you write the jail cells until they can't escape. Then you'd refactor the code cleanly removing unneeded cells, and removing bars that are in the wrong location, and test again. Prisoners didn't escape. You don't have to communicate with the jailor. And you could deliver the entire castle once you've finished it all. At that point the jailor says that the dungeon needs more cells, and now you've got to dig up more of the foundation.

Agile TDD Castle

If you combine Agile and TDD. You'd see if the prisoners escaped, then ask the jailor what's needed. He says you need more cells. You'd go grab some random people to pretend to be prisoners and see if they escape. If they don't, then you show it to the jailor, and he's happy with it. Then you start building the parapets.

Conclusion

So both solve different problems. Agile helps with changing requirements based on discovering users needs as they see the product develop at the point in the process where it's easiest to adapt. It involves releasing stable additions broken up from the overall design.

TDD solves the problem of anticipating failure. Discovering and correcting failure as it occurs at a point in the process where it's easiest to fix. It involves testing stable de-coupled units of code broken up from the overall design.

It's easy to see TDD as an extension to Agile, because they both follow the same pattern, unit driven progress and review. The difference is that the units in Agile function externally to-date as a whole, whereas the units in TDD function as a part, and may not produce a functioning product for external review. And both processes govern different needs (usability vs. correctness). Since both function over a process of developing in units, both review processes can occur at similar points, with TDD being more finely divided.

Notes

• Having unit tests alone does not mean you use TDD. TDD means having the test before the produced unit, and using the test as you develop to confirm the unit. Unit testing without TDD can be used to make sure you don't invalidate previously built functionality.
• Having sprints and other meetings doesn't make you agile. The goals of the manifest makes you agile. You can break up waterfall goals into sprints with units-of-work, without meeting the commitment to favor people over processes.
• By definition of TDD and Agile. Your unit-tests will govern non-deliverable units, and so TDD will cycle faster than Agile. And if you employ both, your Agile cycles will contain one or more TDD cycles (if every unit is tested).
• From what I understand: You fail Agile by failing to develop a deliverable / meaningful unit to the user. The unit can be meaningful even if it speeds up the product. But how does Agile explain refactoring for easier maintenance? I haven't covered it enough to answer that.
• You fail TDD by failing the unit test. Producing code that doesn't produce the feature correctly.

Answer 9

Agile forces you to address and mitigate schedule and quality risks at every iteration. i.e. TDD is not needed to be considered Agile.

However, TDD is a tremendous technique for mitigating quality risks, especially for a project with a large number of iterations or people. In such a project, TDD will add some schedule risk in early iterations, because you have to write test cases too. However, TDD yields huge costs savings in later iterations because it continuously mitigates quality risks. i.e. TDD is recommended.