Toehold Test

Let’s write a small class that has potential to grow.

data class ZipCode(val code: String) {
  init {
    require(code.matches(Regex("""\d{5}"""))) {
      "not a zip code: $code"
    }
  }
}

Should you write a unit test for this? Turbo test-driven developers do because they obsess over test coverage and test everything! But what about us pragmatic developers who are in a hurry, and who aren’t obligated by process?

I claim that we should! Not to defend against regressions, but instead to serve as a toehold for further tests. Someday somebody may extend this and it’ll be helpful to have a test to build upon.

This is particularly worthwhile when the test requires setup. If your obviously-correct code needs a fake clock or a temporary directory to be tested, the toehold-test’s job is to configure that stuff. That way there’s no friction to testing when it’s most useful.

If you need inspiration, name the toehold test happyPath()!