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?
5
-
77Testing is a necessary part of any quality software development.– TelastynCommented Sep 25, 2014 at 0:38
-
2possible duplicate of Can you be Agile without doing TDD (test driven development)? - if you disagree let me know...– MurphCommented Sep 25, 2014 at 7:58
-
11I disagree with the duplicate. Testing is broader than TDD and the broader question has different answers.– Bart van Ingen SchenauCommented Sep 25, 2014 at 8:52
-
I agree with @BartvanIngenSchenau. Not only is testing a far broader activity than just doing TDD, but TDD and unit testing are not the same. I'm surprised so many people confuse the last two.– Andres F.Commented Sep 25, 2014 at 21:26
-
It may have been folded into the concept of "Definition of Done", which in Agile/Scrum means it is context-dependent. When Agile is applied to marketing, sales etc., they don't have similar concepts as software testing, but still have a "definition of done". For software, "definition of done" should consider the quality (both visible and internal e.g. code quality) of the end result, as well as the level of testing that has been performed.– rwongCommented Sep 26, 2014 at 0:42
Add a comment
|
5 Answers
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.
-
2It is also important that future incremental changes do not break previous functionality, and unit tests are an easy way to check for that.– user22815Commented Sep 25, 2014 at 2:54
-
1I'd say testing is absolutely essential for software development. Commented Sep 25, 2014 at 21:28
-
@Snowman Testing != unit testing. Also, unit testing != TDD (just in case...). Commented Sep 25, 2014 at 21:28
-
@AndresF. true, I normally think of unit testing being an integral part of Agile for the reasons I outlined above. Reading failure.– user22815Commented Sep 25, 2014 at 21:40
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.
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.
-
13
-
3You could prove it correct. Clean Room Software Engineering is very similar to TDD, actually, but it only has automatically generated statistical tests that are generated from the specs and proofs. Commented Sep 25, 2014 at 18:20
-
1-1 - "Testing shows the presence, not the absence of bugs."– TelastynCommented Sep 25, 2014 at 21:05
-
@Telastyn, Not having tests shows the presence of bugs with near certainty. On the other hand, a well-written set of tests provides an executable specification of what your code does.– DimaCommented Sep 26, 2014 at 12:29
-
I don't disagree, but no amount of testing proves that your code works.– TelastynCommented Sep 26, 2014 at 14:24
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.
answered Sep 25, 2014 at 21:01
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.
