Home Blog CV Projects Patterns Notes Book Colophon Search

Overlapping Tests

18 Jan, 2017

Programmers don't like to do unnecessary work so we often write tests not to overlap.

I think this can be a mistake.

We all know that tests should test the interface you care about but not the implementation, but in order to write tests like this in a microservice context, the service itself is the interface you care about. This means you often end up mocking any external data access (the code that makes an HTTP request to another serivce, the call to execute some SQL from the database etc). This means you've tested quite a long way down, and that you can change almost anything in the service however you like without needing to change tests, as long as you don't change behaviour. All good! Choosing anything higher up to mock begins to get into the realm of testing implementation.

Now, it is likely you also want to test the services you are calling really do work, and it is also unlikely that the low-level code you mocked in the previous tests are the best way of doing this. The answer is simple, the new code you want to call marks a new interface. Just test that and its actual HTTP response too.

The massive advantages of overlapping this way are that:

You don't get bugs where your data one side of a boundary isn't the same as that on the other
You aren't doing huge amounts of work to change implementation
You get a re-usable library as well as a microservice