Exhaustive testing is the name given to a test approach, which uses all possible combinations of test inputs to verify a software system. This approach is only applicable to tiny software systems or components with a close finite number of possible of operations and allowed data. In the majority of software systems, it is not feasible to verify every possible permutation and input combination, and therefore exhaustive testing is just a theoretical approach.

For that reason, it is said that the absence of defects in a software system cannot be proved. This was stated by the computer science pioneer Edsger W. Dijkstra (see quote at beginning of this chapter). Thus, testing is, at best, sampling, and it must be carried out in any software project to reduce the risk of system failures (see chapter 1, Retrospective On Software Quality And Java Testing, to recall the software defect taxonomy). Since we cannot test everything, we need to test properly. In this section, we review a set of best practices to write effective and efficient test cases, namely:

• Tests should be simple: The software engineer writing the test (call him or her tester, programmer, developer, or whatever) should avoid attempting to test his or her program. In regards to testing, the right answer to the question Who watches the watchmen? Should be nobody. Our test logic should be simple enough to avoid any kind of meta-testing, since this would lead to a recursive problem out of any logic. Indirectly, if we keep tests simple, we also obtain another desirable feature: tests will be easy to maintain.
• Do not implement simple tests: One thing is make simple tests, and another very different stuff is to implement dummy code, such as getter or setters. As introduced before, test is at best sampling, and we cannot waste precious time in assessing such kind of part of our codebase.
• Easy to read: The first step is to provide a meaningful name for our test method. In addition, thanks to the JUnit 5 @DisplayName annotation, we can provide a rich textual description, which defines without Java naming constraints the goal of the test.
• Single responsibility principle: This is a general principle of computer programming that states that every class should have responsibility of a single functionality. It is closely related to the metric of cohesion. This principle is very important to be accomplished when coding tests: a single test should be only referred to a given system requirement.
• Test data is key: As described in the section before, the expected outcome from the SUT is a central part of the tests. The correct management of these data is critical to create effective tests. Fortunately, JUnit 5 provides a rich toolbox to handle test data (see section Parameterized tests in chapter 4, Simplifying Testing With Advanced JUnit Features).
• Unit test should be executed very fast: A commonly accepted rule of thumb for the duration of unit test is that a unit test should last a second at the most. To accomplish that goal, it is also required that unit test isolates properly the SUT, doubling properly its DOCs.
• Test must be repeatable: Defects should be reproduced as many times as required for developers to find the cause of the bug. This is the theory, but unfortunately this is not always applicable. For example, in multi-threaded SUT ( a real-time or server-side software systems), race conditions are likely to occur. In those situations, non-deterministic defects (often called heisenbugs) might be experienced.
• We should test positive and the negative scenarios: This mean that we need to write tests with for input condition that assess the expected outcome, but we also need to verify what the program is not supposed to do. In addition to meet its requirements, programs must be tested to avoid unwanted side effects.
• Testing cannot be done only for the sake of coverage: Just because all parts of the code have been touched by some tests, we cannot assure that those parts have been thoroughly tested. For that to be true, tests have to analyzed in terms of reduction of risks.