echnologies such as the xUnit framework, combined with Maven, BuildBot, 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 base?a 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 files?one 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.

This Language Has No Good Testing Framework!
Once upon a time, languages weren’t designed to host test libraries. Developers were supposed to write good code right from the start. Languages have evolved since then, but you still have to handle huge code bases in these older languages, which definitely would benefit from unit testing. The most basic way to deal with such languages is to write a large number of small programs, each of them representing a test. Then you can encapsulate and run these programs within a new language that has a testing framework. This is certainly not a very elegant solution, but it works.

A more advanced approach is creating entries in your tested software that you could access with an external language. If your tested program is developed with C/C++, for example, you could create entry points and access them through Python (SWIG anyone?). If your old language creates a Windows DLL, you could use quite a few languages and frameworks to test the DLL entry points. The drawback to this solution is that you add non-functional code to your software, and the added software could itself contain a bug. But adding it will probably help you refactor your code.

There Are Bugs in These Underlying Libraries!
Sometimes your unit tests pass on nearly every platform, but the application encounters bugs on a specific version of an OS. The reason may be that annoying bugs exist in a library on this platform. Because you followed the library specifications and simulated the library with mock objects, you did not see the bugs within your unit tests. If you can’t fix the library itself, you can employ two strategies to deal with this:

• Consider your unit tests incorrect because they don’t cover all test cases. In this strategy, you redesign some of the mock objects to simulate the library bugs and then cover this behavior in your unit tests. I personally disapprove of this option, however. Unit tests can be considered specifications, and writing unit tests to describe a library bug is like specifying a bug for subsequent generations of the code.
• Consider your unit tests correct (and they are, considering the specification of the library), but create integration tests to properly test your application anyway. The integration tests integrate several pieces of the application code together to have them tested against the actual environment (file system, database, network, and so on). Some of these tests will fail, and you will have to refactor the code to circumvent the faulty library behavior.

In either case, creating integration tests is always a good thing. They test your code in a more realistic situation than pure unit tests. Unit tests work with expected behavior of small and isolated pieces of code, whereas integration tests put the code in real situations, such as accessing a real database instead of mock objects. Once you begin using them, you will soon find yourself wanting to automate and manage them (continuous integration again). But automating integration tests is usually a pain because it requires much more context handling, such as recreating a clean database before you run them. Unit tests are obviously much simpler to automate.

Integration Tests?Unit Tests “Lite”
Realistically, you will face situations when you can’t create unit tests at a reasonable cost. This unfortunately is the case with tightly coupled code, test-averse legacy code, and buggy libraries. If you want to introduce true unit tests in the long term, you can definitely make a good continuous integration system out of (less unit-like) integration tests.