Practice writing specific tests

We have previously looked at automated tests, and how to make them specific, fast and deterministic in the presence of concurrency. But there are many other properties that we want our tests to have; some of my favorites are:

  1. Inspiring, ie. each passing test gives you confidence.
  2. Specific, ie. the cause of failure is obvious from the test.
  3. Predictive, ie. no failure means all is good.

(For more properties see Kent Beck’s excellent post Test Desiderata.)

These all have a common theme of specificity. (1) states that a test should not test zero properties. (2) states that a test should not test multiple properties. (3) states that collectively our tests should be complete.

Writing specific tests is difficult because we need to spot how code can fail. To help with this we have several heuristics, such as testing the boundaries, or Myers heuristic: “You can test many positive cases together, but only one negative at a time.”


To help practice writing specific tests I have constructed a GitHub repo with nine different versions of the same function. They all look natural, but all have bugs, except for one. Sort of a Where’s Waldo but with bugs. The function has a fairly simple purpose:

  • take an array of floats,
  • find the average, and
  • subtract the average from each element.

The exercise is straight forward: construct a test suite to weed out all the bad implementations. Keep in mind:

  • A good test tests something — ie. fails at least one of the erroneous programs.
  • A good test is specific — ie. fails as few implementations as possible. (Only one of my tests fail more than one implementation.)
  • A good test is correct — ie. never fails the working implementation.
  • A good suite should be complete — ie. fail all but the working implementation.

My final test suite has 11 test cases, how many does your solution have? Comment below.

If you like this sort of thing, you are probably proud of being technically proficient, then you will probably also like my refactoring book:




I live by my mentor’s words: “The key to being consistently brilliant is: hard work, every day.”

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

DevOps vs SRE: looking at the variance between the two in 2021

Is Woz U a Coding Bootcamp? — Woz U

Cronos Testnet Deployment

CS373 Fall 2020: Marika Murphy blog: Week of 5 Oct — 11 Oct

Welcome to the Field — Grab a spade

JetElements Dynamic Data Addon. The Key to Adding Dynamic Content to JetElements Widgets

CSS Grid Layout — Fast and Furious

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Christian Clausen

Christian Clausen

I live by my mentor’s words: “The key to being consistently brilliant is: hard work, every day.”

More from Medium

Introduction to JVM(Java Virtual Machine) - Part 04

Find All Articulation Points In A Graph

JVM part 02 — Inside Java Virtual Machine

Builder Design Pattern