Hacker News Reader

Comment by smokel | Hacker News Reader

This is a great example of where unit testing does not apply.

I see many developers get caught up in rituals, and polishing (and monkey testing for that matter) seem to go against a reproducible approach, and are therefore frowned upon and even ignored. Still, it is a much more powerful technique to get something both working and user friendly.

Investing in developers to spot that something is 3 pixels off, or the basic idea that different users have different tastes, can be very productive.

View on HN

It is also very easy to develop systematic automated ways to do this with tools like Playwright and Nut.js.

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.

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.

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).

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.

Reply on news.ycombinator.com