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

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.