Category: Test Code Quality

Tests let you know that you broke the expected behavior. If you break the behavior and the test suite is still green, something is wrong with your tests. That may happen because of weak assertions (which we have discussed) or because the method is covered but not tested (this happens, as discussed). Also recall that…

Tests exist to assert that the exercised code behaved as expected. Writing good assertions is therefore key to a good test. An extreme example of a test with bad assertions is one with no assertions. This seems strange, but believe it or not, it happens—not because we do not know what we are doing, but because writing…

A repeatable test gives the same result no matter how many times it is executed. Developers lose their trust in tests that present flaky behavior (sometimes pass and sometimes fail, without any changes in the system or test code). Flaky tests hurt the productivity of software development teams. It is hard to know whether a flaky test…

You want tests that either help you find bugs or help you document behavior. You do not want tests that, for example, increase code coverage. If a test does not have a good reason to exist, it should not exist. Remember that you must maintain all your tests. The perfect test suite is one that can detect…

Tests should be as cohesive, independent, and isolated as possible. Ideally, a single test method should test a single functionality or behavior of the system. Fat tests (or, as the test smells community calls them, eager tests) exercise multiple functionalities and are often complex in terms of implementation. Complex test code reduces our ability to understand what is being…

Tests are a developer’s safety net. Whenever we perform maintenance or evolution in source code, we use the feedback from the test suite to understand whether the system is working as expected. The faster we get feedback from the test code, the better. Slower test suites force us to run the tests less often, making…

What does good test code look like? There is a great deal of literature about test code quality, which I rely on in this section. Much of what I say here can be found in the works of Langr, Hunt, and Thomas (2015); Meszaros (2007); and Beck (2019)—as always, with my own twist.

You have probably noticed that once test infected, the number of JUnit tests a software development team writes and maintains can become significant. In practice, test code bases grow quickly. Moreover, we have observed that Lehman’s law of evolution, “Code tends to rot, unless one actively works against it” (1980), also applies to test code. A…