Help, My Code Isn’t Testable! Do I Need to Fix the Design?
Posted by Jakub Holý on September 9, 2012
Our code is often untestable because there is no easy way to “sense1” the results in a good way and because the code depends on external data/functionality without making it possible to replace or modify these during a test (it’s missing a seam2, i.e. a place where the behavior of the code can be changed without modifying the code itself). In such cases the best thing to do is to fix the design to make the code testable instead of trying to write a brittle and slow integration test. Let’s see an example of such code and how to fix it.
Example Spaghetti Design
The following code is a REST-like service that fetches a list of files from the Amazon’s Simple Storage Service (S3) and displays them as a list of links to the contents of the files:
Why is the code difficult to test?
- There is no seam that would enable us to bypass the external dependency on S3 and thus we cannot influence what data is passed to the method and cannot test it easily with different values. Moreover we depend on network connection and correct state in the S3 service to be able to run the code.
- It’s difficult to sense the result of the method because it mixes the data with their presentation. It would be much easier to have direct access to the data to verify that directories are excluded and that the expected file names are displayed. Moreover the core logic is much less likely to change than the HTML presentation but changing the presentation will break our tests even though the logic won’t change.
What can we do to improve it?
We first test the code as-is to be sure that our refactoring doesn’t break anything (the test will be brittle and ugly but it is just temporary), refactor it to break the external dependency and split the data and presentation, and finally re-write the tests.
We start by writing a simple test:
Refactoring the Design
This is the refactored design, where I have decoupled the code from S3 by introducing a Facade/Adapter and split the data processing and rendering:
In practice I’d consider using the built-in conversion capabilities of Jersey (with a custom MessageBodyWriter for HTML) and returning
This is what the test looks like now:
Next I’d implement an integration test for the REST service but still using the FakeS3Facade to verify that the service works and is reachable at the expected URL and that the link to a file content works as well. I would also write an integration test for the real S3 client (through S3FilesResource but without running it on a server) that would be executed only on-demand to verify that our S3 credentials are correct and that we can reach S3. (I don’t want to execute it regularly as depending on an external service is slow and brittle.)
Disclaimer: The service above isn’t a good example of proper REST usage and I have taken couple of shortucts that do not represent good code for the sake of brevity.
1) Introduced by Michael Feathers in Working Effectively with Legacy Code, page 20-21
2) ibid, page 31