Here is the total number of unit tests our entire code-base had when I took over: 0.
That’s right, none at all.
Making changes to this code was a nightmare, as small changes in one place could cause things in other places to fail without warning. I made it a priority to get some unit tests in place for the old code, and all new code would have tests long before it got anywhere near production.
We settled on using PHPUnit for unit tests and Behat for behavioural tests.
We also stipulated that Test-Driven Development would be done. Some team members found this too difficult and so they refused to do it – they wrote the tests after writing the code. But, I always say you don’t get better at doing something by avoiding doing it, so if a decision has been made to use TDD, you’ve got to persevere.
I seemed to spend a lot of time writing tests for code that had none, which helped with figuring out how PHPUnit worked, and demonstrated to me the value in doing TDD. Writing tests after the fact soon brings the poor quality of some code to light. Having to create lots of mocks and stubs just to get a class to instantiate in order to test it, for example, shows that a class has too many dependencies. Mocking lots and lots of method calls reveals a class that is doing too much. I would even say I can now determine which code was written using TDD and which wasn’t.
Our biggest project now has over 55,000 unit tests, but still only has around 80% coverage. Clearly, not everyone agrees with using TDD – but enforcing its use is something else.