For the last six months or so the traditional process of releasing the latest version of our company website has been simplified and automated by one particular bright-eyed, talented young developer with a penchant for Ruby.

As the company’s CSS/UI/Front End guy this technical stuff is way out of my remit, but the end product has been hugely useful for the IT team as a whole; my single biggest benefit is being able, with a single click in TeamCity, to publish websites to various test servers.

So whilst the automated wizardry has being going on around me, I haven’t followed how it’s been happening, but I’ve understood why; getting everything automated saves time, right?  So why not get my front-end work in on the act?

With a goal of automated CSS testing I spent time trying to figure out exactly what could be tested as part of my day-to-day work? Obviously making websites look pretty is a subjective task, so where can you fit an automated check into the process?

I’d come across some IE6-crashing CSS bugs that I thought I could prevent with unit testing, but after recreating the bugs there were always CSS and Javascript, so not the sort of problems I was trying to solve (automated JS tests, such as Selenium or JSUnit are well known already).

The first step then was to ask the people who know, so I tagged up my question with “css”, “unit-testing” and “automated-tests” on Stack Overflow but didn’t get the answer I wanted (always the fault of the questioner apparently).  So it was back to Google, but not knowing quite what you’re asking always makes it harder to find the answer.

In the end the best (aka only) automated testing of CSS and HTML I kept being told was the good-old W3C validation.  Now I don’t know about you guys, but “this site is valid XHTML and CSS” was a label I always put proudly across every site I developed.  Or at least it was back in 2004.

In the years since I’ve not validated my HTML.  Not because I don’t think it’s worthwhile, but because the sites I’ve been working on are .Net monoliths, where getting an ampersand encoded is a two-day job for someone else.  It just didn’t seem worth the effort when every browser knew how to display your site anyway.

CSS validation was easier to run and easier to fix, but it always broke on those nice fun new CSS3 values, so why bother?

Despite my modern ambivalence towards validation I wanted some automated testing sufficiently to overcome the problems. After some further research I went to our Ruby dev and suggested we put a CSS validation step into our automatic build.

So we sat down at my computer with a copy of RubyMine open and he carefully talked me through my first Ruby programming. Whilst he was nice and patient and talked me through each line of code, I’m left with only a general understanding of what I wrote!

A summary of our work then is all I can offer.  Firstly you need to install the Ruby w3c_validators gem, against which you run your validation.  Secondly we defined the folder against which we wanted all CSS files to be checked.

Finally we created an exclude.txt file listing the CSS files we didn’t want to be checked.  This includes our IE6 file, print file and minified versions of our stylesheets.

Here’s a txt file of the ruby we use, hopefully it may help – W3C CSS Ruby validation.

So where are we now?  Well, we immediately found ourselves with a breakage as a hundred or so “errors” stopped the build in it’s tracks.  A hundred errors?!  This is why he didn’t want to validate you’re probably thinking.

Well not quite.  As I mentioned earlier the W3C validate against the latest released version of CSS, 2.1, whilst throughout 2010 I’ve been adding little flourishes to our site with a splash of CSS3.

The solution? Well, it took a little time, and some might disagree that it’s the best approach, but I’ve created separate stylesheets for our CSS3 (incidentally using Sassy CSS, but that’s for another blog).  These CSS3 files can now be added to the exclude file and we have a validated stylesheet, that is automatically tested and part of the build.

So there it is.  It’s not sexy – validation never has and never will be sexy – but we had demonstable valid CSS, and I get to add “this site uses valid CSS” to my company’s footer.

PS. This first step we have implemented is CSS2 validation.  My plan is to add HTML validation to a cross section of our site’s page templates, but I’ll blog about this when we implement it in the new year.