Main menu

A fully-automated testing rig #2

2 July 2014

Part 2: Setting up for a large project

When you take on a project it's a good idea to make sure you plan ahead. Testing platforms only remain useful as long as they're considered dependable - if it becomes too difficult to write tests which don't reliably execute you might as well not bother.

Here are a few key things I set up at the start to help the project along, which have all been hugely worthwhile investments:

A sensible directory structure.

It sounds like an obvious thing, but I had 25 content types to start with, and more content types, pages and functionalities would need testing in the future. Each test script would also need PhantomCSS config set up, a standardised workflow and ideally to have key variables externalised. To have everything in one giant script was out of the question, and having 100 lines of repeated code in every file also would be inconvenient - it would not be fun to have to change every script by hand just to make small updates to PhantomCSS' config!
The final structure involved having a tests directory and a utilities directory. The tests directory would be able to contain subdirectories of tests, neatly categorised. This would also allow us to run only one group of tests, by simply changing the test suite directory given to CasperJS; from tests to tests/appearance, for example.

A test script template.

We wrote up a basic test script outline which most scripts should stick to - which makes test scripts easier to update because they all follow the same structure (yay standardisation!). This also allows the other developers on the team to get started much more quickly, as it both gives them an easy starting point and makes for a library of tests which are easier to dissect and copy.

A wrapper script.

Even better than just having a nice directory structure was the decision to wrap CasperJS in our own shell script, so that we can just add opts and parameters to make it, say, run specific tests, give pretty console output (or plain console output for Jenkins - the colours don't show up nicely), create a new imaging baseline or test the site at a different URL because we want to check the preproduction server for release.
Command-line scripting takes a little learning, but it's saved a whole lot of time!

About the author

Nathan is a recent Masters of Computer Science graduate from the University of Warwick, and has lots of little chunks of experience in a variety of languages and arenas.
He is currently the main developer for our automated testing ambitions.

Comments

Hey I know this is off topic but I was wondering if you knew of any
widgets I could add to my blog that automatically tweet
my newest twitter updates. I've been looking
for a plug-in like this for quite some time and was hoping maybe you would have some experience with something like
this. Please let me know if you run into anything. I truly
enjoy reading your blog and I look forward to your new updates.

Comments on this article are now closed, if you want to give us feeback you can use our contact form instead.