Extract from SitePoint Article “Creating Tests for Your Sass Framework” by David Khourshid
Published June 18, 2015
So you’ve written (or want to write) an awesome Sass toolkit, framework, or even a small function or mixin, and you want to share it with the world. Fantastic! That’s what’s great about open-source software development — you get to collaborate on code with other supportive developers in the community to create useful software that many can benefit from.
But, not so fast! It’s very important to test your software before releasing it. One of the most efficient ways to do this is with unit tests, which are automated scripts that test if a single function of a single unit of code behaves according to a defined specification.
Sass gives you the ability to manipulate data using functions, operators, variables, and control directives and expressions. The return value of a @function can also be tested directly against the expected value. For CSS output and visual regression testing, a tool like PhantomCSS is better suited for the job, though @mixins can be tested in the latest version of True.
We will be using Eric Suzanne’s True testing framework for unit testing sample functions in Sass, but the guidelines presented are applicable for any Sass testing framework. For simple tests, you might want to use a minimalistic (and awesome) Sass testing framework such as Hugo Giraudel’s SassyTester.
Setting Up
True can be installed as a Ruby gem (gem install true) or a Bower package (bower install true). Configuration options can be found in True’s documentation. From there, a load path can be set up to point to the True installation.
Keep test files in a separate directory from your Sass files. This is so that tests can be easily .gitignore-d and exempt from accidental Sass watching and compiling. If a project is mainly a Sass project, the directory can simply be named /tests, with the main test file located at /tests/tests.scss.
Inside the /tests directory, it helps to organize your tests by module, which is usually by the @function or @mixin it represents. Sometimes, similar functions and mixins can be grouped in the same module.
// Sample Sass project structure
/css
/scss
/tests
/api
_foo.scss
_bar.scss
_all.scss // imports foo and bar tests
/helpers
_baz.scss
_qux.scss
_all.scss // imports baz and qux tests
tests.scss // imports api/_all and helpers/_all
index.html
package.json
// ... etc.
The main test file, tests.scss, will be responsible for importing and reporting all of the tests and the actual SCSS project that will be tested:
@import 'true';
// Import the project
@import '../scss/project';
// Import the test files
@import 'api/all';
@import 'helpers/all';
// Run the tests
@include report();
Testing Functions
In order to effectively unit test functions, it’s best to collect the specifications of the function being tested. In a modular architecture, each function has a single responsibility — it has one job, and usually returns the same type of value.