Help, My Code Isn't Testable! Do I Need to Fix the Design?
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:
publicclassS3FilesResource {
AmazonS3Client amazonS3Client;
// ...
@Path("/files")
publicStringlistS3Files() {
StringBuilder html =newStringBuilder("<html><body>");
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.
In practice I'd consider using the built-in conversion capabilities of Jersey (with a custom MessageBodyWriter for HTML) and returning List<S3File> from listS3Files.
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.