graphical interfaces to quixote test cases
keturn opened this issue · comments
(brainstormy stuff here, let me know if there's a better forum for speculative feature discussion.)
Trying to unravel the thoughts around my not-quite-a-question following this evening's demo:
I look at the code in the tests, and the feedback given by the failing assertions, and I think
A) this is explicit and precise, which is great, I can really see this helping bring confidence to shipping CSS on multiple platforms and refactoring it.
B) This is written with labels and words and numbers, and there might be a lot of cognitive load involved in translating that to a box-model picture in your head to figure out what it's trying to tell you. (and I don't often have a lot of that left over after spending it parsing karma's console output.)
How could we narrow that gap?
For comparison, we can look at something like Chrome's developer tools, which has a number of features one might want to integrate with or replicate.
- Hover over something in the rendered page, it highlights that element's source in the DOM.
- Hover over a node in the DOM source view, it's highlighted on the rendered page (with element content distinct from its padding).
- Adjust values in the CSS or element's style and see those changes reflected on the page (in something near real time).
How might those sorts of interactions apply to quixote?
- click on element in browser, choose "go to test"
- click on a block of CSS in webstorm, choose "Go to test (⇧⌘T)"
- click on an assertion in a test, say "show on page"
- and highlight which things it is making an assertion about (i.e. if it's only making an assertion about top-left but not right-edge, distinguish that)
- Wraith's path of pixel-by-pixel comparisons clearly leads to madness, but perhaps taking a screenshot on assertion failure would be useful to for a visual to accompany assertion's message in the output.
- one better: can you not only say "118 pixels higher than expected", but show the expected position on that screenshot?
- I haven't figured out how to get inline images in a jetbrains source view yet, but having thumbnails next to your test cases might be useful for recognizing them. (or maybe not at all helpful, if they're all "it's a picture of a box ... next to another box.")
Taken to a Light Table-like extreme (and yes, I did watch a Chris Granger presentation recently), you might have a multi-pane view with the rendered page, the stylesheet source, the test, and the test results... and you'd want to have the test results for all your platforms to keep you honest, lest having one rendered view there in front of you lull you in to a false sense of security.
I haven't yet really dug in to WebStorm's debugger stuff, at least not as it relates to the DOM, but it might turn out that such an interface isn't all that far-fetched.
Okay brain dump OVER. Thanks for the thought-provoking demo!
Interesting ideas! My first thought is that this would be better as an add-on to Quixote rather than part of Quixote's core. Also, I'd suggest using Quixote to test-drive something real first, if you haven't yet, before you draw conclusions about what's needed. I haven't personally found the non-graphical nature of Quixote's output to be a problem. The TDD cycle is so detail-oriented, and it's so much about driving CSS coding (also non-graphical) that it's not really been an issue.
Closing this--it's a major project best done as a separate tool.