Is Test Driven Development Agile? [closed]

Question

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.

---

This question does not appear to be about programming within the scope defined in the help center.

Closed 5 years ago.

Improve this question

From the agile manifesto, agile values:

Individuals and interactions over processes and tools,

Working software over comprehensive documentation,

Customer collaboration over contract negotiation,

Responding to change over following a plan

Yet doesn't TDD create a plan and almost structure out a contract negotiation?

"What are the features you want?" "1,2,3" Developer writes tests for 1,2,3 -> Team delivers code "Here's 1,2,3 give us our money"

It's also a form of comprehensive documentation and also a process. Once the tests are written individuals and interactions no longer matter as much because the "source of truth" is no longer with people but ironed out in the code.

Just wondering how they fit together, if they're opposed or do they work together?

Answer 1

TDD is more like a practice for individual contributors, instead of a process. Test here usually refers to unit test, which is part of development work, instead of comprehensive test suits such as performance, functional, and integration tests.

TDD in certain cases should help individual contributor really think about requirement and implementation (respond to change and come up with working software). I personally do not adopt this practice, but it is an agile practice that can be adopted by a single contributor. Do not confuse it with higher level tests and related documents.

Answer 2

Yet doesn't TDD create a plan

Nope. TDD does not mean "write tests up front" it means "write tests before writing code". The whole "Do as much as you need and no more" comes into play. You are not expected to write the tests for all your features before writing any code, just the feature you are currently on. And then (depending on the level of testing) just a small subset of the feature will need tests now.

It's also a form of comprehensive documentation and also a process

It also aids with working software.

Working software over comprehensive documentation,

Over, not instead of. If you can get both, great.

the tests are written individuals and interactions no longer matter as much because the "source of truth" is no longer with people but ironed out in the code.

The oracle for what it does is always the code. The oracle for what it should do is always people. TDD done well also aids with the communication.

Any insight as to why some people seem to be getting mad at the question?

The question comes off as very troll-y. You are twisting the manifesto to make it sound like anything that aids the latter is "bad" and you are twisting the definition of TDD to be an all-encompassing, completely up-front process. Neither of which are true.

Individuals and interactions over processes and tools,

BDD is a great tool for aiding interactions at a dev/BA/stake holder level. TDD (xUnit and alikes) are great tools for aiding interactions at a dev level.

Working software over comprehensive documentation

TDD helps create working software.

Customer collaboration over contract negotiation

(BDD) Being able to describe in a common language the specification and have that execute is awesome.

Responding to change over following a plan

A well tested code base can change with ease. An untested or badly tested code base is fixed.

That is, while there is value in the items on the right, we value the items on the left more.

Answer 3

I also agree with Tom’s answer, ‘if it is possible to do agile well, then I believe that is always a good thing. If it is not possible to do it well, then I believe that it can be harmful.’ Agile simply isn’t the right answer for every company. It is different to do well in a large company and it’s lack of focus on software architecture can really affect the usefulness of the resulting technology. Digital Animal have written an interesting article on Agile and why it doesn’t work for them. http://digitalanimal.com/blog/slaying-the-agile-dragon-the-game-of-thrones-methodology/?AT=D8c953