Posts Tagged ‘unit testing’

Recently I spent a good twenty minutes tearing my hair out over a JavaScript unit test I was trying to write. The answer turned out to be a difference in the way our Mocha-based DOM differs from how it would running JavaScript in a browser.

For example, let’s say you have a select field.

<select name="test" id="test">
	<option value="">Select an option</option>
	<option value="1">Option 1</option>
	<option value="2">Option 2</option>
</select>

In a browser, the top option would be selected by default, so if you had the following code:

jQuery('#test').val();

It would output a blank value as you would expect. However, run this in Mocha and you will get an undefined or a null. The reason is Mocha doesn’t select the top option by default unless you manually specify it to. So your HTML would have to look like:

<select name="test" id="test">
	<option value="" selected="selected">Select an option</option>
	<option value="1">Option 1</option>
	<option value="2">Option 2</option>
</select>

In which case, it would then return the value as it should.

If you’re trying to run PHPUnit from the terminal in Mac OSX Lion, you may get an error similar to the following.

File/Iterator/Autoload.php failed to open stream

You can resolve this by running the following commands.

curl http://pear.php.net/go-pear.phar > go-pear.php
sudo php -q go-pear.php

PHPUnit should now run without errors (or at least, without errors in their code 😉 ).

The problem with unit testing is that developers don’t want to write them. No surprise, there, they aren’t the most exciting thing in the world, unless you’re actually a tester and they are your pride and joy.

So, the challenge for creating a good development and testing cycle is how to ensure your developers are motivated to actually write the unit tests. Test driven development is a good way to go about this, and helps stop developers over-engineering too, but it requires a radical shift in your workflow.

Perhaps a less extreme modification, and one developers are more likely to buy into is to replace functional testing with unit testing.

Back in the old days, when you were working on a web application for example, you would write some code, you would then load it up in your browser and see if it worked. If it did you would move onto the next thing and if it didn’t you would go back and fix it.

Then the rise of unit testing for web applications came along and developers were asked to write the code, functionality test it and then write a unit test for it. But none of them did because they didn’t want to write a boring unit test.

However, recently I was writing a model for a web application. Having made my changes, I then wrote a new test for it in our set of unit tests to ensure that it worked as it should. I ran the tests, and I did. But, being pressed for time, I never actually ran a functional test on it. But it worked. Which is no huge surprise, given it passed the unit test.

But what if that was policy? All you had to do was to write the unit test and for it to pass that, you didn’t have to do a functional test. Developers might buy into that, because it takes roughly the same time (probably a little more, but not too much to worry about) and you don’t lose too much. Here is why:

You can’t get away from functional testing. At some point, someone is going to have to do a functional test and at that point they will see if it works or not, and knock anything that doesn’t work back to the developers. This isn’t the case for unit tests – you can go without them, it just means you end up producing pretty rubbish unreliable code and end up spending ages tracing issues down later. But it isn’t an in your face blocker, so developers often ignore it.

Of course, I wouldn’t recommend this for organisations who already have a testing culture embedded. But for organisations that don’t currently unit test, relaxing your rules on functional testing could help you take that first step down the road.

I’m currently consulting at a small software house in Leeds city centre and we’re making continuous integration a big thing.

Initially, we started off using CruiseControl which integrates nicely with phpUnderControl. Unfortunately, phpUC is now seriously showing its age – many of the components simply didn’t work anymore and it still uses phpDocumentor, a project that was abandoned years ago to the point where it is now unusable with modern code (though I’m glad to see the project has recently been rescued and a 2.0 version is being developed).

As a result, we’ve now switched to Jenkins and it’s really working out well. it seamlessly integrates with Subversion and using the Ant build script we’re able to integrate PHPUnit, PHP CodeSniffer, PHP Copy & Paste Detector and PHP Mess Detector, all of which provide great feedback on the standard of code which is being written.

You can then varying the log level and what classes as a failed build, so if you want to ensure everything is absolutely perfect, you can have Jenkins email you every time someone doesn’t quite space their code out right, or adds a local variable that they never use. Then again, you can just have that stuff running in the background and check it when you have time.

One issue you might run into when first integrating such tools is that builds can take a long time to run – CodeSniffer and Mess Detector can take up to 10 minutes each even on a small code, when there are lots of issues to resolve. However, once you have resolved most of these issues you will find that they run quickly again and should be able to get your build time down to a couple of minutes on even a large codebase.