Specifications not Tests
Stop writing tests. I want you to stop writing tests for your code. Stop writing tests and start writing specifications.
Judgement
Tests render judgement. You can fail a test. And if you fail a test what does that make you? A failure.
Specifications do not render judgement. You can confirm to a specification or you can not confirm to a specification. That is a choice you get to make. If you are writing an email server, you will probably want to confirm the IMAP
specification. If you are writing a first-person shooter you probably won’t.
Chronology
Tests come after the fact. You learn fractions, and then you take a test. You build a car, and then you crash-test it.
Specifications come first. Before you build anything you need to first identify what you are building.
Optionality
Tests are optional. You can test the waters, or you can just dive in. You can take a blood test, or you can assume you’re fine.
Specifications are not optional. If you don’t specify what it does, how do you know you are done writing it?
Naming
You may already be writing specifications but calling them tests. Call them specifications. Names are important. If you don’t believe that, rename all of your variables and methods by drawing letters from a bag of Scrabble tiles.
Random names are still far better than names that are misleading. Calling a
specification a test is like calling a saddle a seat. The distinction is subtle
but very important. If you treat a saddle like a seat after a few miles your
butt is going to hurt.
If it comes before the application code, is necessary, and isn’t used to judge
developers then you are not writing tests, you are writing specifications. Call
them that. If your specifications are used to drive the application development, then you are doing specification-driven development. Call it that.
The idea for this essay originated in a Twitter conversation with Dave
Brady. It was further expanded for a lighting talk I gave at &:conf.
I am a lead consultant at Ministry of Velocity. We train engineering teams on refactoring, advise on DevOps automation, and build world-class applications in Rails, Go, and JavaScript. You should work with us.
