I decided to take a look at automated testing of CSS, and I think it might be a useful thing to do. I’m not suggesting laboriously testing every last style, but checking some of the important properties seems to be both possible and potentially time-saving.

For about six years now, most of my programming has been test-driven development. It’s no longer a thing that I do because I feel I ought to: I do it because it’s an effective and efficient way to build and maintain working software.

Nonetheless, there are a few areas of software in which F5-driven development (the make-a-change-and-reload approach) is the norm, and that’s especially true for visual stuff. To some extent, that’s sensible: the important thing about styling a website or application is that it looks good, and that’s very hard to test objectively.

I’ve been working on some CSS over the past few days. One of the typographic principles that I want the stylesheet to conform to is the notion of vertical rhythm, so, to assist me, I set up a bit of JavaScript to toggle a striped background on and off, and peered at my elements to see if they were lined up.

After spending a while doing this, and making fixes that broke things elsewhere, it occurred to me that I could probably automate this process, and that it would be easier, more accurate, and less frustrating if I did so. I knocked together a quick implementation, and asked around to see if anyone else was doing something similar, and was pointed at a few examples, though nothing that seemed to be actively maintained or used.

Today, I’ve expanded my initial implementation into a test library that I’ve called tcsst (I suppose it’s a bit unpronounceable).

The approach that I’ve taken is that tests are defined in terms of selectors to which they apply. The test body will be run against every matching element, and one or more assertions can then be made against each element.

For example, to go back to my vertical rhythm check, I define a test that applies to almost every block element, and assert that the top of each of them is a multiple of the line-height as set on the body. tcsst prints some typical test runner output to the console, and adds highlighting to elements that failed the test.

My imaginary workflow is to create a number of dummy documents that exercise the layout in various ways, and to run the tests against each. This could also be used to test responsive design, by running the tests in browser windows of different sizes, and it could all be part of a full-stack test suite, once I’ve implemented a way to get the results out of the browser and back into a calling process.

You can see what I’ve done so far on GitHub: tcsst.