Documentation as Code

I remember being blown away when I first saw Cucumber roughly a decade ago. It was like writing documentation, and then executing the documentation against your actual codebase. Wow!

A decade later I firmly believe that automated tests should be thought of first as documentation that can also be executed, even just your plain old unit tests.

We’ve all seen codebases where an initial enthusiasm for unit testing slowly erodes as the tedium of maintaining low-value tests doesn’t seem worth it anymore. Tests are commented out when they break, and eventually new tests are no longer added.

And we developers hate writing documentation! It’s tedious, docs get out of sync with updates to the codebase, and nobody reads it.

Well, I like to think of automated tests as a chance to write useful documentation for once.

And that’s why I believe the #1 most important quality of a test is readability!

As Roy Osherove says in The Art of Unit Testing:

Readability is so important that, without it, the tests we write are almost meaningless.

Tests are stories we tell the next generation of programmers on a project.

So rather than piling tests onto a codebase just to see a code coverage metric go up, let’s ask: Have I made the codebase easier to understand today?