Slide 1

Slide 1 text

CSS testing for serious developers … and for everybody else

Slide 2

Slide 2 text

Hi, I’m a serious developer. I do real stuff. I make banks go live, help shops sell stuff online. I add value.

Slide 3

Slide 3 text

I do a lot of Java. Enterprise. I build back-end systems. Server- side. I mean, I am not old fashioned.

Slide 4

Slide 4 text

JavaScript for example. I do write some things here and there. You know. If something needs to look fancy.

Slide 5

Slide 5 text

And I think a lot about quality. Testing. TDD. I do it. Build pipeline, you know it. I even use fancy things like Jasmine. For JavaScript. When going to production everything is well tested. Really everything. Well, basically everything.

Slide 6

Slide 6 text

We test the things you can test, right? Not stuff like CSS… I mean you can’t test it, can you? I’ve never heard anybody do it.

Slide 7

Slide 7 text

I don’t think you should do it. It is just design. You don’t want to have everything in your pipeline. And it’s not a biggie anyway…

Slide 8

Slide 8 text

Although, just recently we couldn’t deploy a critical bug fix. The release candidate shipped with a broken layout on the front page. Our product owner didn’t want to go live with that. That was crazy. Only because of some broken CSS.

Slide 9

Slide 9 text

There you are, putting hours into testing your server-side code, and a tiny issue with your layout… Of course we did give the front- end developer hell for that.

Slide 10

Slide 10 text

It would be cool though to just know that this stuff is fine. I did have our intern google for that the other day.

Slide 11

Slide 11 text

He came back saying there where some people out there hacking on testing just that, too. Rule 34 seems to apply to tech stuff, too.

Slide 12

Slide 12 text

That’s what he found: •  Cactus (https://github.com/winston/cactus/) Ruby & Selenium •  Sassquatch (https://github.com/d-i/Sassquatch/) SASS based prototype •  CSS critic (http://cburgmer.github.com/csscritic/) In-browser & PhantomJS

Slide 13

Slide 13 text

Cactus "   For Ruby "   Uses Capybara to test actual values using Selenium "   One TW projects is already doing a trial run on it Cactus.expect(".header”, "font-size").toEqual("24px");

Slide 14

Slide 14 text

Sassquatch "   Just a prototype for now "   Tests SASS (& SCSS), not CSS "   Idea: Use SASS functions to test SASS in SASS grid-columns { five-columns-at-960px { expect: to-equal(grid-width(5), 400px); } }

Slide 15

Slide 15 text

CSS critic "   Test CSS based on Screenshots "   Run tests against an older reference rendering "   Done by Yours truly "   Internal-Alpha release ;) " Link to screencast on youtube I won't show now csscritic.compare('basket.html');

Slide 16

Slide 16 text

Goal "   CSS can be critical to a web application going live just as any other component. "   Testing your CSS is an addition to your Continuous Delivery approach. "   Keeps you safe during refactorings. "   Keeps your “UI Dev” from being blamed for broken pages. "   Already helping projects go live right now!