Test Culture Episode 6 : Unit Tests Are Better Than Excellent Specifications

Let me rephrase : GOOD unit tests are better than excellent specifications.
Unit tests actually ARE the specifications.

It’s Mathematical

Here’s the equation :
  • Excellent specifications = Very refined exhaustive view of future potential features
  • Good unit tests = Very refined exhaustive view of actual features
The trick is :
  • If you write detailed specifications, you’ll have to implement them as unit tests anyways.
  • Hence : you specify twice.
  • Worst : you need more budget to maintain your specifications because it’s a static Word document.
  • On the contrary :  my unit tests evolves with the real feature. Otherwise it crashes my integration host (remember last episode ?)

It’s The Economy Stupid !

So what is the real goal of specifications ?

Money.

Specifications in a static form are not useful to actually write the code.  They are to conduct dialogs like this :

Client : Hi, this software is nothing close to what I expected.
You : Hi client. I don’t care that’s what you approved. Look, it’s here in the specifications.

Do you really use specs for maintenance  ? Do you think people will go through the pain of reading 3561 pages of outdated information ?
No.  They’ll look at the code. And what could be better than looking at precise explicit unit tests. They are concise and easy to read (of course if they are good). They are even interactive.

It’s In The Process

Specifications work like that :

  1. The client describes roughly what he wants to a specification writer.
  2. This person works for 10 days trying to describe in a very precise fashion what could happen in the finished product.
  3. He then hands it the project manager who estimates costs and delays and assign this task to a developer.
  4. The developer starts implementing a feature. He looks at the specs and starts to code. He develops the main classes. Maybe he is already late because the PM was wrong in his estimations.
  5. Then he stops and goes strait to the person who wrote the specs (if he’s still here) and asks for details.
  6. Then goes back to his workbench, and does some manual tests.
  7. Then back to the spec-person for more precision, then back to his code, and manul tests.
  8. The integration tester gets the feature and does some tests.
  9. Then back to the dev for corrections.
  10. Back and forth  again and again.

At the end the client has a feature that doesn’t look like the specs nor his wish.

It’s In Agile

That’s why the Agile thinking appeared. It’s like Toyota Lean Thinking applied to software production. The goal is to progress by little bits  and be sure the client makes regular corrections along the road.

The Agile + Unit Tests  process would be :

  1. Client writes a user story (a light specification of a feature according to his real need)
  2. He hands it to a developer for estimations and costs. They agree on priorities if budget is limited.
  3. Developer writes unit tests to embrace a lot of aspects of the future feature. He can must  ask details to the client directly.
  4. Developer  writes the code.
  5. Developer runs its unit tests and correct what’s wrong.
  6. Integration tester does some remarks (a lot less than before) based on his knowledge of the business need.
  7. Developer makes some corrections.
  8. Back to integration and then deliver.

In this process you see that specification-writer and project manager are not very important. But that’s another debate.

Specifications are really a monument in some company.
A very few people could refrain from throwing a chair in your face when you’re showing them the useless of detailed specifications. But if you want to deliver great software in time, you should learn to crouch.

Todo

  • Try to find some old specifications,
  • Then compare them to the real feature,
  • Then see how your users actually use it.
  • Is there a real gap ? How much did you spend in specifications that could have been spent in client collaboration and unit testing ?

For the developers out there

Do you need long detailed specifications to start coding  or to maintain a software ? What’s the minimum you need ?

Author: Jean-Baptiste Rieu

Trained software engineer and now product manager. I ❤️ #space #architecture #typography #books #games #verticalfarming. I do #productmanagement #software #abtesting #data. I work on #payment @sundayapp_ Blogging mostly to practice writing, and to engage with others on life in Korea, products, engineering, books and anything worth geeking about.