Sass Unit Testing02 Apr 2014
We need to think about long-term maintenance as our Sass projects and libraries gets more and more powerful. Just look at some of the things Sass can do today, things nobody would’ve imagined just a few years ago:
The term Sass unit testing is not referring to visual regression testing of the visual end-result, but instead logical unit tests focused on the core functions of a library. The term is also not referring to linting of
scss, if that’s what you’re looking for scss-lint may be for you.
The logical testing of functions that an entire project relies on, just makes plain sense – additionally creating tests upfront prevent regressions later. Testing your individual functions will force you to break up your code into small modular functions, and maybe even adopting techniques like object oriented css.
If you’re using continuous integration in your deployment process you are probably already running existing tests before deploying, the first step to making sure your Sass doesn’t break on deployment is making sure that it can compile with errors.
In case you’re already using Grunt for your local development workflow it would make sense to just make Grunt run your test and build tasks. If you’re using Travis it’s just a few simple steps to make your Grunt tasks run on every new build.
No matter what build system you are using, the key is that the build will fail if compilation of Sass/Compass fails - the last thing we want is for broken output
css to make it into production.
A BDD-style framework that doesn’t rely on any frameworks.
Bootcamp is developed by James Kyle who have done some crazy things with Sass, checkout his GitHub. The syntax for Bootcamp is clean and obvious, especially if you’ve worked with BDD frameworks in other languages before. You begin a new test suite by calling the mixin
describe with the title for the spec suite and then the
@content block inside:
Specs are called by the mixin
it which just like
describe takes the name/title and a
@content block. The spec contains at least one expectation which evaluates to either
false, a spec with at least one
false assertion is a failing spec.
The syntax for defining suites and specs are important, but the matchers that are available in assertions are just as important. Bootcamp comes with a bunch of rich matchers already included. An extensive list and demo of each matcher is right here.
It’s possible to disable suites and specs by changing the mixins to
xit, just like Jasmine.
A TDD-style framework inspired by QUnit.
After installation you’ll need to add the following line to your
It can also be installed with Bower or by copying the Sass directory from the project.
After install creating a test suite is a simple as creating a main test file.
We as a community need to figure out what it is that we want to test. What is missing in the current frameworks and maybe even in the Sass language. How are we going to do unit testing in Sass in the future.
Do we want a standard set of assertions and matchers in the Sass language, which we as a community can build different language/syntaxes on top of?