Tests Make Better APIs

Testing things in isolation may give a better view of your APIs.

After reading the integration tests chapter, you may end up with the impression that I don't like unit tests¹.

Actually, I think they provide some good intrinsic values.

For example, as mentioned before, they can provide a better look at the adherence to the design.

But, at the same time, they give a better view of your internal -- and even external -- APIs.

For example, you're writing the tests for the view layer -- 'cause, you know, we write everything in layers; layers on top of layers² -- and you're noticing that you have to keep a lot of data (state) around to be able to make the calls to the controller. Or that you have similar calls, but the parameters are sometimes switched (say, one function gets a token and a user ID, and another function gets a user ID and a token -- why?) That's a sign that you may have to take a better look at the controller API.

Not only that, but take, for example, the fact that you're working on a library -- which will be called by someone else -- and you're writing tests for the most external layer, the layer that will be exposed by that library. And, again, you're noticing that you have to keep a lot of context around, lots of variables, variables coming from different places and similar calls using parameters in different ways. Your tests will look like a mess, don't they? That's because the API is a mess.

Unit testing your layers makes you the user of that layer API, and then you can see how much one would suffer -- or, hopefully, enjoy -- using that.