4 ms·

Why You Should Test Your CSS

31 points by dko 14y ago

goblin89 14y ago
Speaking of testing visuals, there's an interesting project called Sikuli[0] that seems to do exactly the thing. Core idea looks like easy inexact image matching + Python scripting environment. This approach seems to eliminate the need to test CSS, accounting for all kinds of cross-browser issues. It's like the most high-level integration test possible, which looks kind of appealing. I haven't had a chance to try Sikuli myself yet though. Probably there are other similar tools. [0] http://sikuli.org/ http://sikuli.org/, was featured on HN a couple of times as well.
misterjangles 14y ago
I think this could definitely help with some of the bulk testing which would be fantastic. It seems like it might be difficult to test really complex CSS (which is the stuff that probably needs the most testing) like drop-down menus, interactive hover effects, etc. I've definitely had those times where we've tweaked a stylesheet only to find out later that some page deep in the site now caused a floated div to move to the next line and mess up the layout. It would be so great to have unit testing to keep an eye on these kinds of things.
- dko 14y ago
  It seems like it might be difficult to test really complex CSS like drop-down menus, interactive hover effects, etc Such complex CSS behaviors are probably better off being tested by an integration test. It would be so great to have unit testing to keep an eye on these kinds of things. Agreed! The Cactus approach does work well for unit tests.
toemetoch 14y ago
The single most annoying aspect in CSS (IMO) is class and id names, or better: keeping them predictable (we already used that one) and concise (that one should be named that). I'd like to know if there's a simple "namespace convention" that works. As features get added, I always end up making up class/id names or waste time hunting them down. Especially dynamically generated stuff.
ricardobeat 14y ago
A test looks like this: Cactus.expect("p", "font-size").toEqual("12px"); That doesn't make any sense. It's exactly the same as p { font-size: 12px; } just in a more verbose language. CSS has no logic, just rules. Rules are already "tests" for themselves. Visual matching is whole other story that might be useful. Set some tolerance for deviations that trigger alarms on deploy - that could be a lifesaver for IE and mobile support.
- cleverjake 14y ago
  You wouldn't be using it in this case. This would be being used to test inheritance (p {font-size: 10px} #aPTag {font-size: 12px} etc), and the like. If you work on any large scale site, there can be all kinds of things that crop up because a dev thinks they aren't going to impact anything by removing a tag in a class selector.

31 points by dko 14y ago

Speaking of testing visuals, there's an interesting project called Sikuli[0] that seems to do exactly the thing. Core idea looks like easy inexact image matching + Python scripting environment. This approach seems to eliminate the need to test CSS, accounting for all kinds of cross-browser issues. It's like the most high-level integration test possible, which looks kind of appealing. I haven't had a chance to try Sikuli myself yet though. Probably there are other similar tools. [0] http://sikuli.org/ http://sikuli.org/, was featured on HN a couple of times as well.

misterjangles 14y ago

I think this could definitely help with some of the bulk testing which would be fantastic. It seems like it might be difficult to test really complex CSS (which is the stuff that probably needs the most testing) like drop-down menus, interactive hover effects, etc. I've definitely had those times where we've tweaked a stylesheet only to find out later that some page deep in the site now caused a floated div to move to the next line and mess up the layout. It would be so great to have unit testing to keep an eye on these kinds of things.

dko 14y ago
It seems like it might be difficult to test really complex CSS like drop-down menus, interactive hover effects, etc Such complex CSS behaviors are probably better off being tested by an integration test. It would be so great to have unit testing to keep an eye on these kinds of things. Agreed! The Cactus approach does work well for unit tests.

toemetoch 14y ago

The single most annoying aspect in CSS (IMO) is class and id names, or better: keeping them predictable (we already used that one) and concise (that one should be named that). I'd like to know if there's a simple "namespace convention" that works. As features get added, I always end up making up class/id names or waste time hunting them down. Especially dynamically generated stuff.

ricardobeat 14y ago

A test looks like this: Cactus.expect("p", "font-size").toEqual("12px"); That doesn't make any sense. It's exactly the same as p { font-size: 12px; } just in a more verbose language. CSS has no logic, just rules. Rules are already "tests" for themselves. Visual matching is whole other story that might be useful. Set some tolerance for deviations that trigger alarms on deploy - that could be a lifesaver for IE and mobile support.

cleverjake 14y ago
You wouldn't be using it in this case. This would be being used to test inheritance (p {font-size: 10px} #aPTag {font-size: 12px} etc), and the like. If you work on any large scale site, there can be all kinds of things that crop up because a dev thinks they aren't going to impact anything by removing a tag in a class selector.