This is something that’s been in my peripheral vision for some time now. I’ve periodically been struggling to see the need for unit testing in general, without any justification. I can obviously see the benefit of making sure that your code all works and, seeing as I frequently work on ecommerce sites, I can see it causing far fewer headaches when making changes to purchase processes – simply being able to run a script to see if anything I changed works right.
However, one drawback of unit testing as a concept is that computers are, as a rule, infallible when it comes to this sort of thing. Humans, on the other hand, are completely fallible. If I make a change to some code in my checkout process that has a knock-on effect I didn’t count on in my unit testing (like changing the way delivery is calculated/stored/whatever), I wouldn’t necessarily foresee there being any problems in the email that gets sent after a transaction is completed (that may seem pretty esoteric, but it happened today). Part of this issue arose because I didn’t write the original site, and there was no way for me to detect that this could’ve caused a problem without going through every file on the site and manually checking that there was a problem, but another part could have been solved if a good unit testing framework was in place.
Now, when I say “good”, what I really mean is “comprehensive”. Anyone can write a good unit testing framework and here’s how, in my opinion. You test /every single dependency/. Everything. Bar nothing. If unit testing could’ve solved my problem today, it would’ve been done a little something like this (not exactly like this because the code on this site is largely a mish-mash of procedural and I-don’t-quite-understand-OOP-so-I’ll-give-it-my-best-shot – I assume it would’ve been very difficult to express this as a unit test).
Say I have a method that outputs this email that gets sent. I would write a unit test to capture the output of that method (when supplied with sample data from my database table, for a little extra reliability). I would then take this method and write my own version of it inside my unit test, so that I know it’s correct and compare the output of the two methods. If they differ, I would (PHPUnit) assertSame(legacy_method_output,my_method_output), and the test would pass if I hadn’t fucked it up. Now, the perceptive among you will have spotted something wrong here. In order to write this unit test, I would first have had to know about this email’s pre-disposition to causing problems in the first place. This, in this case, is the entire battle. Furthermore, I would have had to completely rewrite the method, solely to test that the old method hadn’t been broken in some way. For future testing purposes, this is really useful but, chances are I’d just rewrite the method and move on.
All of this isn’t to say that unit testing is fundamentally flawed. Far from it, in fact. I can see that it’s an incredibly useful tool for documentation and future-updates. When I come back to code that already has a unit testing framework, I’d simply make my alterations, run my unit tests until they all pass, then write some more to cater for my currently augmented feature-set. I would then know (with only a shadow of a doubt) that everything is brilliant and nothing is going to get fucked up when I put my code live. That’s got to be worth it! Not only the above, but unit tests seem to me to serve as excellent developer documentation. If you want to know how something’s supposed to work, never mind asking the project manager or client (who probably don’t know, and don’t really care!), you can just look and the guy who wrote it will have told you! Brilliant.
The only (and sadly, this is a pretty substantial “only”) problem is time (as with everything, I guess). You get all of this great peace of mind, but you have to put time into it. And it’s not just a small amount of time either, it’s a lot of time. Once you’ve written all your code (maybe doing it as you go along – 30 minutes a day or something) you then have to write tests to try and break it, and cater for every potential outcome that could arise from user or developer input of the code you wrote. That’s a large investment of time. I can’t quite decide if the net gain is quite worth the input, but I’m tipping towards a yes. I spend a lot of time a bit stressed about whether a modification I’ve made is going to cause unexpected problems, and I’d really like to be able to be more confident with this. I’m also one of those people who likes doing little scripty things, and gets a great sense of satisfaction from ticking boxes and watching “make test” throw out 100% success. Maybe this is for me, after all!