Matt Andrews
Software engineer making apps – that aren’t apps – and more at the FT. 会说汉语.

Automate Sass Testing (with Travis CI)

View my demo project on GitHub

Having a large amount of CSS is unavoidable in a modern web application. Using preprocessors such as Sass help us manage that CSS but as we write more @mixin‘s, @function‘s and adopt techniques such as object orientated css the complexity grows. At FT Labs we even use (or perhaps abuse) npm as a package manager for Sass only repositories for various projects, including the FT Web app, so that those styles can be shared across projects.

With this ever increasing complexity, the differences between writing CSS and any other programming language are eroding.

All this complexity adds risk

In other programming languages we mitigate this kind of risk with automated testing. It’s time to start testing our Sass.

Testing Sass with Travis CI

Sass isn’t a language that Travis CI currently has first class support for but we can get it working with just a small number of hacks to the .travis.yml file.

Apart from some Sass (which I’m assuming you have already) you will need a .travis.yml file that looks something like this:

- "test/travis.rb"

language: sass
- gem install sass

View source file

Here I’m telling Travis to first install Sass then execute the file located at test/travis.rb.

If you use a task runner such as make, Rake, Grunt or another you’ll probably want to use it rather than a script like this but I wanted to keep things as simple and technology agnostic as possible.

Interestingly the language: option is actually optional and it even allows for invalid values – helpfully it will default to Ruby (the language Sass is written in). Optimistically I’ve set it to sass but it may be more robust to set this to ruby.

The test

The next step will be to tell Travis exactly what to build.

Here are the contents of my test/travis.rb script:

#!/usr/bin/env ruby
result = `sass main.scss built.css`
raise result unless $?.to_i == 0
raise "When compiled the module should output some CSS" unless File.exists?('built.css')
puts "Regular compile worked successfully"

View source file

I’m using back ticks rather than any of the other other ways to run shell commands in ruby so I can easily check the status code and output any errors thrown by Sass (which come through via stdout). I then check to see if the built files exists – and raise an error if it does not.

An error thrown at either step will stop the script executing and cause the build to fail.

Protection against bad PR

From now on any Pull Request that causes our Sass not to compile will come with a bright yellow red ‘The Travis CI build failed’ warning.

What can we actually test?

Compiling is a good first step but that offers little more than a linter) and will only catch the most basic of regressions. Here are some other ideas and examples of what could be tested: