Five Unit Test Tips: #2: Change your code to make testing easier

It’s been a while since I promised to write top five unit testing tips, so I guess I should better start writing #2. As with my first example this one is based on a real-life story.

Your code is worth nothing if it can’t be tested. Change your code to make it more testable.

In my last project, we used a pipes and filter architecture, with messages being passed forward through a chain of services. Most services refined the messages or broke them up in smaller services and passed them on to the next service. When they refined the message, they often stored new messages to the data layer as a side effect. To test the results, we read the generated objects back from the data layer. I had code like this:


The solution was to change the design away from the pipes-and-filters design. Instead, the process() method returns the newly created Transaction object:


This new design totally violated our architecture, but it’s clearer, it keeps the infrastructure away from the code, and it’s much less brittle. Our test transaction repository used to be vulnerable to being polluted with test data from a previous run. As we no longer use this sort of infrastructure objects, we don’t have to worry about interaction between tests.

If you don’t know how to test your architecture, the problem is not with the testing, but with the architecture.

Until next time: Happy testing.

About Johannes Brodwall

Johannes is Principal Software Engineer in SopraSteria. In his spare time he likes to coach teams and developers on better coding, collaboration, planning and product understanding.
This entry was posted in Extreme Programming, Java. Bookmark the permalink.