When taking an agile development approach, it is obvious to only implement features when necessary. My question is: can the same be applied when it comes to testing, i.e. creating test cases and only test when necessary, or is that a bad idea?

  • 3
    That's not how it works. Tests are part of the features. If the features are not tested then you don't have releasable features
    – imel96
    Commented Oct 4, 2018 at 3:48
  • 3
    This depends on how you define "necessary". So what do you understand by saying a "test case is (not) necessary"? Please give an example.
    – Doc Brown
    Commented Oct 4, 2018 at 5:39
  • 1
    All tests check things which you think but can't know you've done correctly. Therefore it's not possible to judge which tests are "necessary" or not - they all are. Commented Oct 4, 2018 at 7:20
  • 1
    @KilianFoth: I understand perfectly what you are trying to tell the OP, but there can be indeed "unnecessary tests" - like obviously redundant ones, or tests for missing features which are not going to be implemented in a reasonable time frame. OP were actually not clear enough about what they have in mind by "necessary".
    – Doc Brown
    Commented Oct 4, 2018 at 7:38

4 Answers 4


My question is: can the same be applied when it comes to testing, i.e. creating test cases and only test when necessary, or is that a bad idea?

I don't think that necessary is a good choice of words here, whether you're talking about tests or features. Very often, features aren't added to software because they're necessary, they're added because they're useful or valuable or desirable. Features are added because they make the product better by some metric that's important to the stakeholders.

The same is true of tests, and to an even greater degree. Tests are separate from the product being tested, so they don't directly impact its functionality at all and they're certainly not necessary to the operation of the product. Tests are just tools that help developers and other stakeholders to maintain a consistent level of quality. Tests can help ensure that the product meets requirements; they can detect failures; they can save time and money; etc. In short, tests are often useful, valuable, and desirable, even if they're not actually necessary.

The idea with agile development is to build a minimum viable product and then iterate on that to improve it in whatever direction the stakeholders decide is most important. You can apply the same philosophy to tests: start with a basic set of tests that give you the most benefit, and then iteratively improve in the direction of the most benefit.

Often, tests will be developed in parallel with new functionality, because the tests can be a useful tool during development. For example, an important idea in agile development is to have a common understanding of what it means for a task to be done, and tests are one way to establish the definition of done and to demonstrate that you've met the requirements. But tests can also be developed later — perhaps to demonstrate a bug, or to increase confidence that the product behaves consistently.


Please note, I am biased as a tester.

I would say AT LEAST establishing a basic test plan early in the development process is very important, and testers should be involved in the discussion of new features to help be ahead of the game when it comes to implementing how these features will be added into the test plan.

The earlier you can begin testing, the earlier you catch the bugs that seem like edge cases but a few thousand lines of code later become difficult-to-pinpoint mammoths. It's easier to solve these issues when they're isolated rather than when they're connected to other methods, objects, or whole features.


A pragmatic answer:

When developing new features, TDD (test driven development), can speed up development:

  • Develop (using unit tests) the technical functionality in isolation.
  • Not every secondary method, and not heavily integrated, but as easily combined independent aspects. As otherwise an other approach in coding, small redesign as required by the actual non-test code would require rewriting tests.

  • Then write the non-test code.

  • And add unit tests as API / use-case examples.
  • Complete the high-level code with tests. The use-cases should cover border cases, errors too. These unit tests should better be done last, to not hinder the development impetus. They should not be forgotten though.

This leaves some methods of the low-level aspects not tested. However there is a good chance that the high-level use-cases cover the testing of the functionality of thoses aspects already.

Last but not least: if one uses integration builds with say Jenkins, then a code analysis tool like SonarQube will admonish a missing test coverage. Then one probably should either arbitrarily accept say 85% coverage as "optimal" performance/cost ratio, or work sub-optimally and do a total test coverage.

To recap:

  • as unit-tests are nobodies favorite work, test driven development may alleviate some of the towering work and allow fast results.
  • TDD should be limited to basic functionality.
  • Unit tests on several layers testing the same code actually is redundant IMHO.

Absolutely. Only test when necessary. But slow down: Testing is always necessary.

Seriously, the very latest point in time where you need to test your software is after you think one task is finished and before you start the next task. Because that’s the point where newly introduced bugs come from the feature that is fresh in your mind, so the number of possible causes is limited, and the causes are easier for you to examine.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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