The source content for blog.juliobiason.me
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

1.8 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") }}


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