RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Testing Tips for When Unit Testing Is Too Hard : Page 2

Writing true unit tests is just too difficult in certain scenarios, but you don't have to dismiss testing all together. Here are some tips for making a practical compromise with (less unit-like) integration tests.

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.

Laurent Ploix is in charge of code quality and efficiency at Sungard Front Arena, a Sweden-based provider of integrated cross-asset, end-to-end solutions. He has been developing front office and back office financial applications since 1996.
Email AuthorEmail Author
Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date