+++
title = "Things I Learnt The Hard Way - Tests Make Better APIs"
date = 2019-06-19

[taxonomies]
tags = ["en-au", "book", "things i learnt", "unit tests", "layers", "apis"]
+++

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

<!-- more -->

When I spoke about [integration
tests](/books/things-i-learnt/integration-tests) you may end up with the
impression that I don't like unit tests[^1].

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. 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 the 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.

[^1]: Again, let's ignore for a second that there are no "unit" in "unit
  tests"...

{{ chapters(prev_chapter_link="/books/things-i-learnt/integration-tests", prev_chapter_title="Unit Tests Are Good, Integration Tests Are Gooder") }}