Seeing as how I have my web-dev hat on lately, I've been dealing a lot with CSS, HTML, layout issues, and other sundry.

I crave unit testing. Unit testing is a method where programmers can test the results of any code they create, or (especially) modify, to make sure that it conforms to a set of requirements. It is also called a "test harness" which simultaneously brings images of something that saves your life if you slip and fall down a cliff, and something that binds you.

Unit Testing is practically automatic. When you write code, you write some tests that run along side the code, and when you are ready to "push the change upstream" and make your code live, you run the unit-tests first, to be sure that everything is running well. Running the tests is as easy as clicking on a test button, or launching your favourite build utility; they are painless to run and it only takes just a few mindless seconds.

Web Developers don't have that luxury. Instead, when it is time to test, they have to open at least 2 browsers—though quite likely 4-6 and visually inspect the results. This can get downright physically painful (multiple IEs anyone?). Trying to do any effective CSS refactoring is effectively impossible, because there is no easy way to test the results. Something. Must. Be. Done.

A web development unit tester

A web development unit tester would do something like this:

1. Automagickally validate the rendered HTML page (rendered because changes are you are using some kind of ASP/JSP/PHP funkiness) for valid (x)HTML, CSS, broken images and broken links
2. Visually compare the rendered pages against a set of "templates" to ensure that any changes to the stylesheet or underlying markup don't have any adverse effects.

The first requirement is simple. Painless basically. Validators, of the link, css, html and image variety, have existed for ages. All that it takes is the ability to chain them all together, and launch them from a simple button (or command, if you are strong—GUIs are for the weak). The second requirement is the most important and difficult part, especially if unit-testing CSS is to become a reality.

How can unit-testing happen for CSS?

Not Easily.

Essentially what needs to happen is that a visual representation needs to be compared to ensure that everything "looks good". This fuzzy definition really encodes the problem. One solution I have thought of involves opening the page in all of the target browsers rendering engines, rendering the full page directly to an image, and then comparing the images pixel vs. pixel against a known "last-good" result. If the pixels differ, the offending pixels could be highlighted and the developer could choose to specify that the variation is within acceptable bounds and not be warned about it again, or fail the test.

This would be especially helpful when moving style-declarations around a style sheet, for instance, when pushing up a declaration to a parent element, or down to a child element. These kind of refactorings should change nothing in the visual presentation of the page, but should make the stylesheet smaller, easier to read, and easier to parse: for machines and humans.

Who wants to build this?