A fully-automated testing rig #2

##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:

1. 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.

2. 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.

3. 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!