1. 13
    Unit Testing Principles practices testing olano.dev
  1.  

    1. 10

      This is surprisingly reasonable despite using unit/integration dichotomy! Though, I continue to maintain that the most important insight about testing is that there are two independent axes here:

      • how much IO is done by test (none > some FS access > some IPC > some HTTP to a different machine)
      • which fraction of your codebase is exercised by the test (single function without dependencies > the entire thing)

      https://testing.googleblog.com/2010/12/test-sizes.html?m=1

      There’s also third axes, whether we are testing a single unit of behavior, or a more complicated composite flow, but it is of the least consequences for writing tests.

      EDIT: worth pointing out how the article (and I presume the book) avoids the usual confusion: it re-defines the meaning of unit! It uses neither the original meaning (unit is the test itself, unit of testing, as a encoding of a defined part of a manual testing process in a repl), nor the acquired meaning (unit as a component or module), and instead conveniently defines it as “unit of behavior”. There’s some deep truth in here about naming things!

      1.  

        That definition of unit is one of my favorite take-aways from the book. The Clarity talk mentioned at the beginning does a great job of showing how to use it when testing a feature.