27

Does it make sense to talk about "agile development" or claiming that you are applying an "agile methodology" if the code base you are working on has 0% unit test coverage? (And you, as a team, are not doing anything about it).

To make it clear: to me, it doesn't make sense. In my personal experience I found that unit tests are the only tool that allows you to really be "agile" (i.e. respond to changes, improve your design, share knowledge, etc...) and TDD is the only practice that takes you there.

Maybe there are some other ways, but I still cannot see how they can possibly work.

| improve this question | |
  • 14
    Agile has a much greater chance of succeeding with automated testing to back it up. I've be forced to apply Agile without tests before and it's a trap. It's just a convenient way to accumulate technical debt faster than before. – MetaFight May 30 '16 at 18:42
  • 5
    TDD isn't necessarily the only practice that takes you there. It is a common one, though. Personally, I find BDD to be a more pragmatic approach. – MetaFight May 30 '16 at 18:44
  • 6
    "Agile has a much greater chance of succeeding with automated testing to back it up": so do non-agile projects, for that matter. I think automated testing is rather orthogonal to the methodology used: it makes you more confident that your code is correct and helps you to keep it clean. – Giorgio May 31 '16 at 5:21
  • By the way this question mixed unit test and TDD you can have unit test without TDD. – Walfrat Apr 26 '17 at 14:53
  • Reading the answers here, I'm surprised how much things have changed since I learned agile in the mid 00s. TDD and pair programming were considered the ESSENTIAL agile practices to maintain high quality code at a high pace. – nomen Sep 18 '19 at 21:23
36

To be pedantic, nothing in the Agile Manifesto or the Scrum Guide make any reference to technical practices, like unit testing or TDD, at all. So, yes, in theory you could deliver early and often with a focus on collaboration and value without them and call yourself Agile, you might even actually have agility.

In practice however, it's nearly impossible to consistently deliver value (into production) every few weeks without a good test suite. This includes integration tests as well as unit tests. Unit tests only go so far. There's a reason it's s pyramid and not a rectangle after all.

Without the tests as a safety net, you'll either introduce lots of regression bugs in each release, or be terrified of refactoring. Both will greatly impact your ability to continue on at a sustainable pace. If you can't sustain your pace or change course (redesign) when required, then you don't have agility. Agility, after all, is the goal we're striving for.

| improve this answer | |
  • Do you have to follow the Agile Manifesto to be agile? – JeffO Jun 2 '16 at 12:00
  • No @JeffO. You don't, but it certainly helps. I edited to clarify my intent. – RubberDuck Jun 2 '16 at 16:07
  • 1
    IMO the most agile programmers are those who are very pragmatic even though they have never heard of the agile manifesto. – Giorgio Jun 4 '16 at 10:12
  • 1
    I can't disagree with you there @Giorgio. I was on an agile team years before any of us ever heard of Agile. – RubberDuck Jun 4 '16 at 10:13
  • 2
    @CortAmmon - If you want to define Agile (big "A" agile as in your methodology), I would agree with you, but if you want to be agile (little "a" as in actually being agile so you can handle changes better), then you don't have to follow any particular methodology at all. If you can do waterfall and still handle changes (difficult, but not impossible), who cares? – JeffO Apr 28 '17 at 17:46
29

The agile manifesto simply states:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

No mention of unit tests there. Even the 12 principles do not mention testing.

So, technically, it's possible to be an agile team without writing unit tests. In practice though, it's really hard to see how a team can maintain working software in an agile environment without tests to assist them in making constant changes.

| improve this answer | |
  • 4
    It's hard to see how a team can maintain working software in any environment without tests. – Bryan Oakley May 31 '16 at 19:00
  • 6
    Just because something is hard to see doesn't make it impossible – Ampt May 31 '16 at 19:46
9

Even though that there's no direct word stating about unit testing or TDD or any kind of test in the agile manifesto as others have answered here, I believe that a good Scrum Master or Developer would be able to discern one of the statements in the manifesto.

Working software over comprehensive documentation.

How would anyone know if the software is working? The manifesto need not to explicitly state the term testing. It is succinct.

Unit-testing (in context of the topic) will make your coding phase slow on the earlier stage but will be worth it as you progress, making development a lot faster onwards. It gives you fine grain control on code level testing as well as making your design scalable, giving you confidence that your software is working and can easily handle regression; to which would make your development agile.

| improve this answer | |
  • 3
    You can test it manually. You don't need unit tests for it. They help. A LOT. They are like the top thing that can improve a process. But they are by no means essential to deliver software. – T. Sar May 31 '16 at 18:39
  • Yes, of course. I did not say you can't do it manually. I did say any kind of test. I was not stating any form of disagreement on testing. And as for your manual testing, it's on a different perspective on your end on how you can keep up being agile while facing regressions. – Axel May 31 '16 at 18:51
  • I do understand your point of view. However, the question asks about unit tests in special, not exactly tests in general. Reading your answer on the context of the question makes one consider your testing as "unit testing"! – T. Sar May 31 '16 at 19:00
  • There, sorry for that. – Axel May 31 '16 at 19:13
  • 2
    @ThalesPereira, a unit test that tells you whether the change that you made forty seconds ago broke something is a lot more agile than the report you get back from the QA department telling you that something somebody changed three days ago broke it. – Solomon Slow May 31 '16 at 20:10
2

It absolutely makes sense. Agile is not about testing, as others have mentioned already, but to specifically answer your question:

No, you do not need unit testing at all.

You can run an agile process with integration testing only. You could run an automated integration test nightly for example and fix bugs that are found the next day. You could have a manual tester running integration tests continually if you like. Regardless of the system, unit testing is entirely optional.

You might find unit testing helps you develop, and fair enough to that, but there are many things that can help development that you might not have.

You do need some form of testing though, even if its the old 'customer beta testers'. If your customer is heavily involved in the process and doesn't mind finding bugs, then this can work - as they tend to find bugs that nobody else even thought were bugs!

| improve this answer | |
  • You can run an agile process with integration testing only. Is this theoretical or spoken from experience? – R Sahu Apr 26 '17 at 15:13
1

It's not required. Testing is great when you have people that really know how to use it. When you don't, not only is it not necessary, it becomes a liability. I'd say there are many programmers who are not very skilled at it.

I'm glad you acknowledged in your question that being agile is about how you actually release software instead of following some methodology. The Agile Manifesto is a nice reference, but it's not the definitive guide. Agile existed before it did. There are ways of developing software to be "more agile" but different combinations can be used on various projects.

If you're releasing new software at a pace that is acceptable to the client, you're probably agile. I would also include not having too much push-back and complaining about feature changes by the developers. Fixing one thing only to break another isn't ideal either. When you're users are several versions behind in upgrade, you probably are not very agile whether you test or not.

| improve this answer | |
1

I would like to counter argue (other answers) that the Agile manifesto does clearly state something about this, namely:

Continuous attention to technical excellence and good design enhances agility.

I really like the LeSS definition of technical excellence and it includes unit-testing and TDD. Now you can argue you might not need unit-tests and or TDD to achieve this, but it is the most common and probably advised way.

Organizational Agility is constrained by Technical Agility

In other words, when you are slow in making changes to your product, then it doesn’t matter how you structure your teams, your organization or what framework you adopt, you will be slow to respond to changes.

If you can prevent your product from resisting change in another way you might be on the right track, but:

I invented Extreme Programming to make the world safe for programmers. – Kent Beck

Scrum lacks any technical practises, but Jeff said the following about it:

I have never seen a hyper-productive Scrum team that didn’t use Extreme Programming development practices. – Jeff Sutherland

Quoted from this article: http://ronjeffries.com/articles/017-02ff/gathering2017/

I would expect Scrum teams without technical practises to eventually by using retrospectives come up with a similar practise. You want to be hyper-productive too, not?

The Agile fluence model, mentions it in the two star level:

Useful techniques include continuous integration, test-driven development, pair programming, and collective ownership.

If you target only the first level of Agile fluency you could skip the practise, but any larger and longer running product should atleast try to achieve a two star level.

So the general consensus is that yes without good unit-testing, clean code and refactor practises, currently it is not possible to be truly Agile. This might change in the future as new technical practises emerge.

What do you think the answer would be if we ask some signees of the manifesto like Robert C. Martin, Martin Fowler or Kent Beck? Maybe they will say it depends, but generally it is something you should do.

| improve this answer | |
  • 1
    fact is, it doesn't have to be "unit-test" you could just have integration test running and consider it's enough. However if you have nothing and test everything manually, you will very likely become slow to respond change quickly, or deliver quite a lot of regression ona regular basis. – Walfrat Apr 26 '17 at 14:53
  • 2
    Agreed technically it doesn't, but tests on higher levels are often more brittle, harder to maintain and probably slow you down in the end if you have to many of them. I like how Martin Fowler puts it: "If you get a failure in a high level test, not just do you have a bug in your functional code, you also have a missing or incorrect unit test." from martinfowler.com/bliki/TestPyramid.html – Niels van Reijmersdal Apr 26 '17 at 14:57
  • Test on higher level don't test the same things, so you let holes but consider that currently the risk is worthy enough. For some website that could be enough, for a critical finiancial system -> no way. – Walfrat Apr 26 '17 at 15:08

Not the answer you're looking for? Browse other questions tagged or ask your own question.