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
@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.
In other programming languages we mitigate this kind of risk with automated testing. It’s time to start testing our Sass.
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:
Here I’m telling Travis to first install Sass then execute the file located at
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.
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 next step will be to tell Travis exactly what to build.
Here are the contents of my
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.
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:
@function‘s are relatively easy – test known outputs against known inputs.
- Many CSS libraries, such as @csswizardry‘s grid module offer the option of ‘silent output’. Your test could build the CSS library with the silent flag switched on and assert that the resulting built css file is empty.