echnologies such as the xUnit
framework, combined with Maven
, or CruiseControl
, enable unit testing under continuous integration
, which gives developer productivity a huge boost. However, writing true unit tests even with these tools sometimes is just too difficult. When faced with tightly coupled code, test-averse legacy code, and buggy libraries, developers end up writing tests that aren't quite up to the unit-test standard. Instead, they compromise by running tests that cover several functionalities at once, opening a few sockets, connecting to databases, reading or writing files, and basically abandoning pure unit testing.
This article describes the frustrating scenarios that lead developers to take these shortcuts, and it provides useful tips for dealing with them.
This Code is Tightly Coupled!
Unfortunately, not all software adheres to the best practice of loose coupling, a principle that greatly eases unit testing. For instance, domain objects sometimes are tightly linked to their underlying storage, such as a database. In these scenarios, you can't feasibly test the code without a database. If you tried, it would require refactoring the entire code basea job that may take years.
However, handling software that violates one important principle does not mean you have to dismiss unit testing all together. You can still write useful tests (called integration tests) on tightly coupled code, even though a failed integration test will not indicate the exact cause of the problem. To conduct effective integration tests, you just need to keep the testing environment minimalist, isolated, and constant:
- Keeping the testing environment minimalist has clear benefits. For example, if the code you're testing is tightly bound to a database, there is no need to populate the database with every single test example you can imagine. In fact, you should try to keep things as simple as possible, so as to minimize the amount of investigation time when tests fail. Testing code that is tightly bound to databases also requires you to deal with a lot of different databases for different test suites. If you have to read files, consider applying the minimalist principle by creating a lot of small filesone per test if possible.
- Keeping the testing environment isolated has obvious benefits as well, yet running two test suites simultaneously on a single database is a common practice. This leads to tests failing because the other processes that are running in the same environment change something. You must isolate testing environments as much as possible. One solution is using virtual machines. You can put several of them on the same hardware, while keeping them reasonably isolated from each other.
- Keeping the testing environment constant allows you to rerun tests under the same conditions. If you conduct your tests under continuous integration (and you should), you re-run failed tests so you can debug them easily. So try to keep your environment clean: if you need the file system, unzip a new version of the necessary folders before the tests; if you need a database, reload it prior to testing; if you need the system time, consider using virtual machines with fooled clocks.