Understanding test code that uses external resources can be difficult. The test should ensure that the resource is readily available and prepared for it. The test should also clean up its mess afterward.
A common smell is to be optimistic about the external resource. Resource optimism happens when a test assumes that a necessary resource (such as a database) is readily available at the start of its execution. The problem is that when the resource is not available, the test fails, often without a clear message that explains the reason. This can confuse developers, who may think a new bug has been introduced in the system.
To avoid such resource optimism, a test should not assume that the resource is already in the correct state. The test should be responsible for setting up the state itself. This can mean the test is responsible for populating a database, writing the required files to the disk, or starting up a Tomcat server. This setup may require complex code, and you should also make your best effort to abstract away such complexity by, for example, moving such code to other classes (like DatabaseInitialization or TomcatLoader) and allowing the test code to focus on the test cases.
Another common test smell happens when the test assumes that the resource is available all the time. Imagine a test method that interacts with a web service, which may be down for reasons we do not control. To avoid this test smell, you have two options: avoid depending on external resources by using stubs and mocks or, if the test cannot avoid using the external dependency, make the test suite robust enough. For example, make your test suite skip that test when the resource is unavailable, and provide an alert explaining why that was the case. This may seem counterintuitive, but remember that developers trust their test suites. Having a single test fail for the wrong reasons can make you lose confidence in the entire test suite.
From a readability perspective, it should be easy to understand all the (external) resources required and used by the test. Imagine that a test requires a test file in some directory. If the file is not there, the test fails. A first-time developer may have difficulty understanding this prerequisite. Avoid having such mystery guests in your test suite. The test code should be explicit about all its external dependencies.
Leave a Reply