Skip to main content

A fully-automated testing rig #3

An article from ComputerMinds - Building with Drupal in the UK since 2005
8th Jul 2014

Nathan Page

Developer
Nathan Page
Hey, you seem to look at this article a lot! Why not Bookmark this article so you can find it easily in the future?

Part 3: Using other scripts, datasources and directories

Earlier I described a bit about the scope of the project and how careful planning would be needed to keep the project growing smoothly. One result of this is our test template - 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!).

The template neatly gets most of the key setup/config variables from a config file in the utilities folder. This, though, was harder to get going than we thought thanks to some niggles with absolute and relative directories...

Here are a couple of things I discovered making this work:

1. Sometimes you need to use absolute directories, and that's sort of ok.

Ideally we would write everything to use relative directories, and that's an important thing when the testing server or directory may change or move, but sometimes you just can't do it that way. We spent a while trying to get PhantomCSS to run properly using relative directories, to no avail. In the end, we needed to borrow some useful boilerplate from PhantomJS to make things work. It turns out you can borrow PhantomJS' filesystem module though, and that enabled us to very easily work with absolute directories. Using their API we could then do the following to combine the working directory with the path to PhantomCSS within our project:


# (If this looks weird, it's because it's in CoffeeScript!)
# Get filesystem module from phantomjs so we can find out our current directory
fs = require 'fs'
# Get phantom config info from single location
phantomcss_config = require './../../utilities/phantomcss_config'
# Get PhantomCSS on board
phantomcss = require "#{fs.workingDirectory}#{phantomcss_config.phantomcss_location}"

2. When you start experimenting with directories, they don't all do what you think they'll do.

So we have a directory for utilities and a directory for tests, and our post script is stored neatly in the utilities directory. When the post script runs, from where / relative to which directory does it run? Ten points for the correct answer... The answer, oddly, is the tests directory, and this took a while to figure out. That's right: the post script 'runs from' the test suite directory. This was crazy strange, but we've had to run with it. So here's our post script, stored in the utilities directory, changing over to the utilities directory to access its adjacent config file:


phantomcss_config = require './../utilities/phantomcss_config'

Fun, huh!

3. It is, once you get your directory paths sorted, really easy to externalise your config / datasources.

We simply stored a plain ol' JSON object in our utilities directory, and all our tests can access it. This is used to provide to our scripts both the PhantomCSS configuration and a set of screen resolutions (similar to this gist).

Hi, thanks for reading

ComputerMinds are the UK’s Drupal specialists with offices in Bristol and Coventry. We offer a range of Drupal services including Consultancy, Development, Training and Support. Whatever your Drupal problem, we can help.