Test Concrete Wrapper Classes

Question

If created an interface which contains signatures for the static methods I would have a way to test the classes that were dependent on those static methods.

But how would I test the concrete wrapper class that implements the interface and wraps those static methods?

Do i just not test the concrete wrapper class?

It seems like wrapping the static methods has just moved the problem elsewhere. I still have some class, wrapper class, that is hard to test.

Answer 1

You're on the right track, but you're not moving the problem somewhere else -- you're isolating it to prevent that problem from leaking throughout your code base and other tests. I would only view this as a problem if you've made the wrong assumptions about the wrapped behavior or neglected to prove those assumptions. Some testing is required, but at varying degrees of difficulty. How far you choose to test those assumptions will be a trade-off you need to make.

For some scenarios, the wrapper can be tested but will require physical dependencies that you can control. For example, a static method that modifies a file will require that you take the time to setup the file system, or a helper class that downloads a file from a web-server. I like to think of these tests as "integration tests" instead of "unit tests" as they act upon their dependencies instead of running in isolation. As these tests may take longer to execute that standard tests, you may want to exclude them and run them less frequently than your faster unit tests.

For other scenarios, you may not be able to write a test without considerable effort. For example, you may have wrapped the logic that shows a dialog in a separate window -- testing this logic in code would be a lot work, but launching the application and verifying that it works may be enough. You'll take a hit on code-coverage but to me this is an acceptable trade-off.

The key challenge is understanding the assumptions of the wrapped behavior -- eg, what type of exception is thrown from a remote server if web-request is malformed or the network connection is lost? If you don't capture these assumptions correctly, those faults will bubble up into other areas of your code.