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 https://github.com/rdlowrey/auryn
Tier - D.I. based framework https://github.com/danack/tier
Jig - D.I. based templating phpjig.com
|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)
but they are there
Quality provides value - pay for it out of the marketing budget.
This is commonly known as project management…we are very bad at this.
TDD tests deliver their value when the code is written, so the next slide doesn't apply to them.
|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
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:
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."