Is Testing a necessary part of Agile methodology?

Question

I have been on numerous teams that try to practice Agile methodologies and often these teams are test centric. Is testing a necessary part of practicing the Agile methodology or is it just a XP practice that has been latched on over the years?

Answer 1

Testing is absolutely essential to agile, primarily because agile is based around incremental improvements: the difficulty is that it can sometimes be hard to see how the current changes will effect your old code. The best way to be confident that you haven't broken something is to test it, and to know HOW to test it. That way you find the bug immediately, not down the road when you have forgotten exactly what you did when you were writing the code that broke some old feature.

The reason this is different from more traditional, top-down design type programming is that in that environment its a) very difficult to test until you have the finished product b) in theory you are considering all the design criteria at the same time, and so you are less likely to make a design decision that breaks previous design decisions.

Answer 2

You are probably talking about automated testing, unit tests, integration tests etc. These are more important to agile than manual testing (with testers and such) because they are too slow, thus its not possible to test every small change that you make. Since agile is about fast small iterations, having tests that verify correctness in seconds or minutes, rather than hours or days, is very useful.

Answer 3

If you do not have tests, how do you know your code works?

Edit: the assertion that tests cannot prove that the code works fails to define one crucial term, namely works. What does it mean for a program to work? If you keep this term vague, then there is no way at all to prove or be sure that any program works. Ever.

On the other hand, you can define works as "behaves according to a specification". Now you can not only use tests to show that code works, but the tests themselves can serve as an executable specification of your code's behavior. In other words, a well written test suite defines what works means.

This way of thinking also forces you to re-examine the meaning of a bug. If your code passes all the tests, then there are no bugs in the code. If, despite that, the system does not behave as it should, then its behavior is not correctly specified. I. e. the bug is in the spec, defined by tests.

This approach to software development decouples the functional specification of a system from its implementation, which, according to every software engineering book in the world, is a very good thing. At the same time, this approach ensures that your implementation always corresponds to the functional spec.

Answer 4

No, it's not "necessary"

The principles of Agile say nothing directly about testing.

But It's Highly Advisable

Given Agile's commitment to a sustainable process, continuous/incremental delivery, and software quality, automated testing is the best solution currently available for most projects

Exceptions (as noted by Jörg W Mittag) include provably-correct development tools, meta-programming systems that generate code, et al. But these kinds of systems are rare.

Answer 5

Both Agile and XP try to avoid Big Design Up Front. In BDUF, requirements are gathered, a formal specification is created, then coding is done, then testing is done. This makes sense for well-defined, mission- and life-critical systems like medical equipment, space probes, etc.

Agile avoids this flow because it doesn't work well for problems which aren't well-defined, for example "whatever changes the client asks for this week". We still need a formal specification, so we know what to do and when we're done, but rather than some kind of written document we use code in the form of automated tests.

Automated unit tests are quick to write, quick to run and very modular/decoupled. This makes them a fast way to formally specify and check the requirements.