Hacker News Reader

Comment by handsclean | Hacker News Reader

Ok, how would you use Playwright and Nut.js to discover the OP’s “splinter”? Note I’m specifically asking about discovery, not testing for it once you already know what to look for.

View on HN

I've actually been thinking lately about property based testing for UIs. In this particularly case, there should be an invariant for each entry in a radio button list that the selectable area covers the entire bounding box from button to the end of the label. There are many such invariants you could imagine - every paragraph of text should be selectable by a click and drag, menu drop downs shouldn't hide as long as the mouse is within its area etc. Build up a big enough suite of these tests and you could quite easily integrate them in Storybook or beyond. Probably not something you want to run on every save, but an asynchronous process running somewhere recreating this "sanding" activity would be a worth way of saving time and improving quality.

Obviously this won't catch everything human QA can, but where an invariant can be expressed (navigating then going back should result in being in the right place, as mentioned in the article) it seems good to try and capture it.

If I understand you correctly, you mean to build up one test suite, and apply it to many diverse applications?

I'm afraid that will be pretty hard to accomplish, given that such requirements are not easy to distill from the user interface itself, and impossible to obtain from the codebase (which, by definition, would contain bugs that you'd like to catch).

Perhaps LLMs or a "user interface foundation model" might come in handy to find these implicit requirements, and run tests on the application.

Not sure I’m proposing a single test suite, although some of these invariants are very likely applicable to multiple components or sites. I’m just saying that property based testing ought to be applicable to UIs, but it’s not the sort of thing we’ve experiment with because executing the tests is slow. That’s probably fixable in a practical way that’s still more efficient than human QA for a large class of bugs (including both the back button and non-convex hitbox issues mentioned in the article).

Reply on news.ycombinator.com