quixote

e Wraith where you're testing declaratively (here is a screenshot of the homepage; the actual homepage should look exactly like this ±5% variance). It's roughly equivalent to integration tests (how does my nav 'integrate with' the Window, the header, etc.) vs functional end-to-end tests (does the homepage as a whole work). Given your point of view, that can either give great savings in debugging things (as you've more specificity about what has changed that caused your funky layout) or could be a complete waste of effort. The answer is probably somewhere in between :) I would be interested to hear if there's anyone using a CSS test framework like Cucumber/BDD style tests — as the Galen slides above mention, your designer is probably subconsciously checking things on the page, but they're being exact about it — if we could distill that precision into BDD tests and allow our test framework building blocks to grow over time, would you be able to create a suite of reusable test statements that can be written up by design by themselves?

." Same deal: you think about what you want your CSS to do, write the test, then write the CSS, then improve it. Regardless, these are unit tests (or unit-like tests; I don't want to argue semantics), not end-to-end tests. Each one is focused on testing a specific thing, stay inside the browser process, and you use them to drive development. The key is to use good tools; I like Karma [3] because it allows me to run my tests against multiple browsers simultaneously, including mobile devices. And, with apologies to @Anchor, you should absolutely test using real browsers. There are meaningful differences between browsers and you want your tests to catch those differences. Speed is not a problem if you use good test design and tooling; my Quixote tests use Karma, run against ten browsers, and execute 200 tests / sec. [1] http://www.letscodejavascript.com [2] https://github.com/jamesshore/quixote [3] http://karma-runner.github.io/0.12/index.html