Making the value case for Unit Tests


Maintainer of Imagick and Gmagick extensions.

Closure from callable for PHP 7.1, Consistent Callables for PHP 8.0, Constructor behaviour of internal classes passed PHP 7.0

Auryn - the best D.I. library
Tier - D.I. based framework
Jig - D.I. based templating

Quality or Value

Who to persuade

  • Programmers
  • Sales weasels
  • Project managers
  • Most senior management
  • Financial director (or client's financial director)
Without tests With unit tests
Client find something is broken
Reports a bug
Front line support analyses it
Second line support tries to make repro case
Triaged to a developer who has to drop what they're doing
Developer has to analyze bug Look at broken unit test
This code broke something This code broke something

(Let's pretend these are the only two scenarios)

An hour is not fungible

  • Some time in the next week
  • Immediately at 3pm
  • Immediately at 5:15pm on a Friday
  • Immediately at 3am on a Sunday morning

Value is benefit minus cost

Benefit: Probability test prevents bug occurring in production * cost of fixing bug in production

Cost: Cost of writing test + cost of maintaining test

Total tests written Total value of tests Comfort zone Quality zone

The benefits of quality are less visible

but they are there

  • How quickly can you get working fixes out the door?
  • Does adding new features cause a lot of breakage? This is where you lose customers.
  • Do your customers recommend your product to other people. This is where your business grows. If you need to grow, quality is a better place to focus than features.

Quality provides value - pay for it out of the marketing budget.

What needs to be done

  • Start recording costs
  • Get 'them' to acknowledge the problem
  • Get a budget for tests - with KPI of results
  • Set expectations properly

This is commonly known as project management…we are very bad at this.

How to get to Dublin

Features delivered per week Time Writing unit tests as you go Fixing bugs as you go

Unit tests deliver their value over time

TDD tests deliver their value when the code is written, so the next slide doesn't apply to them.

Time is not fungible

  • If unit tests aren't going to deliver value before a crunch point, then they aren't worth writing (at least not on a value basis).
  • Or if the project isn't going to have much more development done.
  • These are business decisions…tech people can only help the business people make informed decisions, you can't make those decisions for them.
Features delivered per week Time Writing unit tests as you go Fixing bugs as you go

Unit tests scale linearly

Communication and tools don't

Unit tests lines of code written O(n)
Communication between people O(n^2)
Relative cost of automation O(n^(1/c))

n = programmers on a project, c > 1

And if that doesn't work ?

  • Life is short
  • Not your problem, so stop giving a shit
  • Our sponsors are hiring



Making the value case for Unit Tests

Do you work at a company where there are not enough unit tests in place and things are constantly breaking? Or maybe you have a client that always wants new features to be delivered as soon as possible, without enough thought about maintaining code.

How do you persuade people that Unit Tests should be written? And that by writing them you will improve your code quality and make development be easier? And how many unit tests should you be writing anyway?

This talk will help you:

  • Understand exactly how and when unit tests provide value in the development cycle.
  • Who you should be making the case for unit tests to, and what terms you should use to persuade them.
  • Writing unit tests can't always be justified by the value they provide. Sometimes this means you should skip writing tests. Other times you should still write those tests. Learn the difference between these two scenarios!
  • Understand how to plan to tackle a backlog of untested code without dooming your job.
Goodhart's law: “When a measure becomes a target, it ceases to be a good measure.”

"You don't have to do TDD in order to get it right," - the thing that TDD actually does is stop the programmer or manager from saying "right, the code works now, let's ship it and not worry about writing tests, or worrying about if the design is even going to be easy to test."