2.0 KiB
+++ 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.
When I spoke about integration tests you may end up with the impression that I don't like unit tests1.
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.
{{ chapters(prev_chapter_link="/books/things-i-learnt/integration-tests", prev_chapter_title="Unit Tests Are Good, Integration Tests Are Gooder", next_chapter_link="/books/things-i-learnt/tests-in-the-command-line", next_chapter_title="Make Tests That You Know How To Run on the Command line") }}
-
Again, let's ignore for a second that there are no "unit" in "unit tests"... ↩︎