Continuously test your front-end code automatically

When I worked at The Guardian, before committing code to Subversion, unit tests were run against the Java codebase. This is pretty standard. Sometimes, things slipped through and were caught at the Continuous Integration stage where an automated build would perform deeper tests and verify the code integrations of each developer hadn’t broken anything. This approach works extremely well.

When it came to the front-end, the only tests that were run was pushing JavaScript code through JSLint. This wasn’t set up as a pre-commit hook. Rather, it was up to the developer to execute a command-line script that performed these tests. I am in no way complaining about this. It was the first and only place I have worked that actually bothered to set up any formal testing of front-end code.

A few months ago I went to a presentation given by Neil Crosby at Skills Matter. Neil spoke about a project he has been working on that addresses the lack of automated frontend testing.

Most web developers will occassionally validate HTML and CSS, and put their JavaScript through JSLint. If this were automated, a lot of time would be saved. Some bugs can take hours to fix and in the end, for example, all that was missing was a closing span tag in the HTML.

Neil’s come up with a framework, called Frontend Test Suite, that automatically runs frontend code through the above tools. The suite is built in PHP and it is recommended that you install local copies of the HTML Validator, CSS Validator and JSLint so your IP doesn’t get banned.

I followed Neil’s installation steps in the file SETUP, which are briefly listed here:

  1. Installed PHP (didn’t really because it’s already installed with Mac OS X 10.5.7
  2. Installed PEAR
  3. Installed PHPUnit
  4. Downloaded Frontend Test Suite
  5. Installed HTML Validator locally
  6. Installed CSS Validator locally (thanks Jen)
  7. Installed Rhino
  8. Downloaded JSLint.js

I use Aptana regularly so, alongside the project I’m currently working on, I created a new project, dumped the Frontend Test Suite files into it and made the necessary edits to the example file. I execute the tests via the command line but at some point I will set up Aptana so I can execute it from there.

Next I need to workout how to get subversion to run these tests pre-commit.

4 thoughts on “Continuously test your front-end code automatically”

  1. Definitely a cool idea. Have you thought though of extending it to run stuff like browser-based integration tests as well – like stuff written with Fitnesse/Watir/Selinium.

    I don’t really know much about this but how many issues do you find that relate directly to the markup too? e.g. when the customer says ‘This box is wonky’ that translates to ‘div tag missing’?

  2. “Next I need to workout how to get subversion to run these tests pre-commit.”

    Is it not better in a team environment to push all these tests onto your CI machine (whether it be cruise/cruisecontrol or teamcity). Reason being is that the tests are going to take a long time meaning devs will check in less (with SCM, your motto should be ‘check in early and often’!).

    As a developer that is touching the markup and frontend code I should be responsible for running the tests myself. If I don’t, and I mess up my JavaScript then the CI server goes red and I have to buy donuts for everyone.

  3. I don’t bother with Selinium myself. Testers I have worked with do find it useful though.

    I often find myself going round in circles only to realise the mark-up is invalid. Browsers mask problematic mark-up by trying to render something come what may. This often leads you on a wild goose chase into the CSS. By running automated tests against the mark-up, one can have confidence in the quality of code.

  4. Yeah, probably in a team environment, a dedicated CI machine is the place for these tests to happen.

    On the project I start on Monday I’ll be the sole developer. Only front-end code is being developed, then sometime in the future will it be integrated with a CMS, a nasty one at that. There’s no concept of unit testing let alone CI.

Comments are closed.