Question

Suppose you are required to use an unnecessarily complicated, difficult to mock (perhaps it has concrete classes with no virtual interface), and unreliable third-party library that integrates with some external resource such as a socket or a database. You decide to create “wrapper” interfaces/classes to greatly simplify the usage of this library and to allow developers using the wrapper to continue to write testable code. The wrapper’s interface looks nothing like the original interface.

I have a few questions about how to test this wrapper.

1. Should the wrapper be tested without the external resource by developing a method-for-method layer over the bad library that can be mocked?

2. When you test your wrapper classes with the 3rd party library (using the external resources) is this a unit test or an integration test? If the external resource can be embedded in memory during the automated test, is it still an integration test?

3. At what point do we quit mocking and stubbing and say that we have a unit. According to wikipedia “A unit is the smallest testable part of an application.” but I am finding this difficult to measure. If speed is a factor in decide whether or not we are testing a unit, how do you decide how slow is too slow for the test to be called a unit test?

Answer 1

TDD doesn’t say that everything must be unit tested. TDD says that you should write a test first but it doesn’t have to be a unit test.

1. Start with integration test – it will test your logic dependent on wrapper which will communicate with a real component. No mocks here. It is integration test because it tests multiple layers of your application and real component still uses sockets or database access.
2. The integration test will fail because you don’t have your logic
3. Write unit test with mocked wrapper to test the logic
4. The unit test will fail because you don’t have your logic
5. Write the logic to satisfy the unit test (4.)
6. Repeat 3.-5. to get all logic necessary to satisfy the integration test (1.)
7. Repeat whole process with the next integration test

There is no need to write unit tests for wrapper. The main wrapper’s function is to wrap the component. If you write unit test for wrapper you will test that it calls method on the component but in such case you are back at the beginning – how to mock the component? If you write integration test just for wrapper calling the component you are retesting the component (OK this is sometimes handy but in normal scenario you don’t do that).

I recommend reading Growing Object-Oriented Software guided by tests by Steve Freeman and Nat Pryce.