Tests for APIs chapter

content/books/things-i-learnt/_index.md

@@ -12,3 +12,4 @@ template = "section-contentless.html"
 	* [Write Steps as Comments](steps-as-comments)
 	* [Gherkin Is Your Friend to Understand Expectations](gherkin)
 	* [Unit Tests Are Good, Integration Tests Are Gooder](integration-tests)
+	* [Tests Make Better APIs](tests-apis)

content/books/things-i-learnt/integration-tests/index.md

@@ -66,4 +66,4 @@ parts.
 [^1]: There is no "unit" in "unit tests". "Unit test" means the test _is_ a
   unit, indivisible and dependent only on itself.
 
-{{ chapters(prev_chapter_link="/books/things-i-learnt/gherkin", prev_chapter_title="Gherkin Is Your Friend to Understand Expectations") }}
+{{ chapters(prev_chapter_link="/books/things-i-learnt/gherkin", prev_chapter_title="Gherkin Is Your Friend to Understand Expectations", next_chapter_title="Tests Make Better APIs", next_chapter_link="/books/things-i-learnt/tests-apis") }}

content/books/things-i-learnt/tests-apis/index.md

@@ -0,0 +1,45 @@
++++
+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") }}