Every day in our office there is an exchange which goes something like this:
“Man, I just love unit tests, I’ve just been able to make a bunch of changes to the way something works, and then was able to confirm I hadn’t broken anything by running the test over it again…”
The details change daily, but the sentiment doesn’t. Unit tests and test-driven development (TDD) have so many hidden and personal benefits as well as the obvious ones that you just can’t really explain to somebody until they’re doing it themselves.
But, ignoring that, here’s my attempt!
-
Unit Tests allows you to make big changes to code quickly. You know it works now because you’ve run the tests, when you make the changes you need to make, you need to get the tests working again. This saves hours.
-
TDD helps you to realise when to stop coding. Your tests give you confidence that you’ve done enough for now and can stop tweaking and move on to the next thing.
-
The tests and the code work together to achieve better code. Your code could be bad / buggy. Your TEST could be bad / buggy. In TDD you are banking on the chances of both being bad / buggy being low. Often it’s the test that needs fixing but that’s still a good outcome.
-
TDD helps with coding constipation. When faced with a large and daunting piece of work ahead writing the tests will get you moving quickly.
-
Unit Tests help you really understand the design of the code you are working on. Instead of writing code to do something, you are starting by outlining all the conditions you are subjecting the code to and what outputs you’d expect from that.
-
Unit Tests give you instant visual feedback, we all like the feeling of all those green lights when we’ve done. It’s very satisfying. It’s also much easier to pick up where you left off after an interruption because you can see where you got to – that next red light that needs fixing.
-
Contrary to popular belief unit testing does not mean writing twice as much code, or coding slower. It’s faster and more robust than coding without tests once you’ve got the hang of it. Test code itself is usually relatively trivial and doesn’t add a big overhead to what you’re doing. This is one you’ll only believe when you’re doing it 🙂
-
I think it was Fowler who said: “Imperfect tests, run frequently, are much better than perfect tests that are never written at all”. I interpret this as giving me permission to write tests where I think they’ll be most useful even if the rest of my code coverage is woefully incomplete.
-
Good unit tests can help document and define what something is supposed to do
-
Unit tests help with code re-use. Migrate both your code and your tests to your new project. Tweak the code till the tests run again.
A lot of work I’m involved with doesn’t Unit Test well (web application user interactions etc.), but even so we’re all test infected in this shop, and happiest when we’ve got our tests tied down. I can’t recommend the approach highly enough.