The cheapest tests are the ones that get by without a server, without a database and without a browser. They run in milliseconds, and when one turns red, it points at a method. In this lesson you write such tests for the Kladde’s most important rule, the free times of the public booking, and for two of the API’s handlers. Along the way you learn how to find the cases that really check a rule, and how a test stops the clock.

Finding boundaries

A rule like “appointments are available from 09:00 to 17:00” has infinitely many inputs, but only a few places where its result changes. These places are called boundaries. Bugs sit there almost every time: a < instead of <=, one minute too many, a day on which the clock jumps. In the middle of a range, a rule is rarely wrong, at its edge often.

From this follows the method called boundary value analysis:

  1. Write down where the rule’s result changes. For “from 09:00 to 17:00, appointments of 30 minutes”, those are the start at 09:00 and the end at 17:00.
  2. At each boundary, test the case exactly on it and one just before and one just after: 08:30 no, 09:00 yes; an appointment that ends at 17:00 yes, one that ends at 17:30 no.
  3. Take at most one case from each range in between. Whether 10:00 or 10:30 is offered checks the same thing; two tests for it are one too many.
  4. Think of the boundaries that aren’t in the rule but in the world: a day in the past, a full day, the day of the clock change.

With this list, you write tests that really secure a rule, instead of many tests that all check the same thing.