Posts Tagged ‘testing’

There are some great online tools for validating that your website is looking and working well. Of course there are loads of these and many of them we’ve been using for years. Below though, I’ve listed a few I’ve been using the most in recent times or that are often overlooked.

W3C validator

An oldie but a goodie. The W3C validator ensures that your mark-up is valid. This is good for two reasons. One, it will find any problems, missing closing, tags, etc, that may be causing weird problems. Two, it will also point out stuff that you could be doing better like semantic tags and relevant meta tags.

http://validator.w3.org/

Mobile friendly checker

Google are starting to crack down on websites that do not consider mobile users. Of course we all know we should be building mobile friendly websites, indeed, it should be mobile first these days! But it is hard to debug sometimes, especially given the fragmentation of devices.

Luckily Google now provides a tool that will give you a pass and fail, as well as showing you a preview of the site on an Android device. It’s not perfect, sometimes it fails to load assets and you have to come back later, but it is still an awesome tool.

https://www.google.co.uk/webmasters/tools/mobile-friendly/

Google Developers testing tool

Over on the Leeds Restaurant Guide we expose our reviews using the hreview schema. This means that sites like Google can see what ratings we give restaurants and put them directly in the search results. To check it is working correctly, you can use Google’s testing tool.

https://developers.google.com/structured-data/testing-tool/

Facebook Debugger

Recently I wrote about the Open Graph protocol which allows you to tell social networks (mostly Facebook) what titles, images and descriptions you want it to use when sharing a web page.

Facebook have a debugging tool to test your tags are working.

https://developers.facebook.com/tools/debug/

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.