3 ms·

The fundamental problem here is "imperative GUI" incentivizing tight coupling between business logic and presentation. Whereas "declarative GUI" like the brows

The fundamental problem here is "imperative GUI" incentivizing tight coupling between business logic and presentation. Whereas "declarative GUI" like the browser DOM can be understood & interacted by automated tools without instrumentation of the business logic. Adding more tight coupling, by coupling your code architecture to the limitations of your testing framework, seems like going in the wrong direction in most cases. Some programs like games need imperative GUI controls to minimize latency, but trying to automatically test everything in an AAA game is a losing battle. You need QA eyeballs, period (or sophisticated visual AI agents).

PaulHoule 3y ago
I dunno. Sometimes it seems that 90% of the complexity of making web apps is figuring out details, corner cases, and spooky action at a distance with CSS. For crying out loud, the CSS spec comprises 50 documents https://www.w3.org/TR/css-2023/ https://www.w3.org/TR/css-2023/ It's one thing to test that element A has the right classes on it, it's another thing to test that a certain CSS selector that is sensitive to the context works correctly, that precedence rules work as expected, or ultimately the document "looks right".
- pphysch 3y ago
  CSS is (too) powerful but not inherently complex. It is often abused. Ultimately you will need real eyeballs to judge aesthetics. No argument there. But significant QA work can be automated with frontend testing frameworks.
  - rerdavies 3y ago
    I've never been that impressed with the functional coverage you get from front-end-driven testing frameworks, at least those that drive views. Test that interface with models in the front-end, though -- priceless! And CSS is inherently complex, because the rules of precedence are fragile and easily broken.
rerdavies 3y ago
Or unsophisticated agents. A strategy I've used for testing highly visual code: run the test procedure; take a snapshot of graphic output; generate a hash signature of the output (e.g. CRC32); if the signature has not changed, the test passes; if the signature has changed, queue the test to a human for verification; if the human accepts the output, save the new hash signature for the next automated test. The TL/DR: if the output hasn't changed the test passes; if it has, get a human to approve the change. Developers can (and probably should) perform most of the manual verification. It wouldn't completely eliminate test teams for AAA games; but it could substantially reduce the load placed on test teams, allowing them to focus on what test teams do best.
- pizza 3y ago
  Quick and dirty simple solution - nice!

PaulHoule 3y ago

I dunno. Sometimes it seems that 90% of the complexity of making web apps is figuring out details, corner cases, and spooky action at a distance with CSS. For crying out loud, the CSS spec comprises 50 documents https://www.w3.org/TR/css-2023/ https://www.w3.org/TR/css-2023/ It's one thing to test that element A has the right classes on it, it's another thing to test that a certain CSS selector that is sensitive to the context works correctly, that precedence rules work as expected, or ultimately the document "looks right".

pphysch 3y ago
CSS is (too) powerful but not inherently complex. It is often abused. Ultimately you will need real eyeballs to judge aesthetics. No argument there. But significant QA work can be automated with frontend testing frameworks.
- rerdavies 3y ago
  I've never been that impressed with the functional coverage you get from front-end-driven testing frameworks, at least those that drive views. Test that interface with models in the front-end, though -- priceless! And CSS is inherently complex, because the rules of precedence are fragile and easily broken.

rerdavies 3y ago

Or unsophisticated agents. A strategy I've used for testing highly visual code: run the test procedure; take a snapshot of graphic output; generate a hash signature of the output (e.g. CRC32); if the signature has not changed, the test passes; if the signature has changed, queue the test to a human for verification; if the human accepts the output, save the new hash signature for the next automated test. The TL/DR: if the output hasn't changed the test passes; if it has, get a human to approve the change. Developers can (and probably should) perform most of the manual verification. It wouldn't completely eliminate test teams for AAA games; but it could substantially reduce the load placed on test teams, allowing them to focus on what test teams do best.

pizza 3y ago
Quick and dirty simple solution - nice!