Live data from Hacker News

Bombadil: Property-based testing for web UIs

github.com

71–80 of 112 posts

Re: Bombadil: Property-based testing for web UIs

#72
post #13

Struggling to understand what this is or how it works.

Did you have a look at the intro in the manual? https://antithesishq.github.io/bombadil/1-introduction.html If that's not clear, please let me know how we can improve it!

A hello-world example of what it looks like, and what running it would validate, would be nice.

It's all very abstractly described in the README and that intro page you linked.

Re: Bombadil: Property-based testing for web UIs

#73
post #71

Congrats to the team! Is there a video showing someone spinning this up and finding a bug in a simple app? A broken counter app maybe?

Not yet but I definitely will record one soon. I've been working at the debugging UI for Bombadil (some hints at https://x.com/owickstrom/status/2034925537706020978) that will make for a nice cohesive demo.

Re: Bombadil: Property-based testing for web UIs

#74
From your title my immediate thought was "cool, maybe this will move us a bit closer to making components (or the testing thereof) cover accessibility thoroughly by default".

See, the idea with the semantic web, and the ARIA markup equivalents, is that things should have names, roles, values, and states. Devs frequently mess up role/keyboard interaction agreement (example: role=menu means a list will drop on Enter keypress, and arrow keys will change the active element), and with ensuring that state info (aria-expanded, aria-invalid, etc.) is updated when it should be.

Then I checked the Antithesis website. They don't even have focus state styling on any of the interactive elements. sigh

Re: Bombadil: Property-based testing for web UIs

#75

My kingdom for a way to stop this godforsaken industry from stripping Tolkien's fiction for parts.

The AI generated illustration and satire of the poem hurt my soul. Tom doesn’t even have pupils! This output is low quality even for AI generated content.

Re: Bombadil: Property-based testing for web UIs

#76
post #48
post #14

I'm doing propety-based test since years for frontend stuff. The hardest part is, that there is so much between the test inputs and the application under test, that I find 50% of the time problems with the frontend test frameworks/libs and not in our code.

And sometimes you find errors in code that absolutely should never have errors: I found an (as of yet not-root-caused) error in sqlite (no crash or coredump, just returns the wrong data, and only when using sqlite in ram-only-mode). Had to move to postgres for that reason alone. This is part of the reason why I have a strong anti-library bias (and I sound like a lunatic to most colleagues because they "have never had…

> I found an (as of yet not-root-caused) error in sqlite (no crash or coredump, just returns the wrong data, and only when using sqlite in ram-only-mode).

You should report this to the SQLite developers - they are very smart and very interested in fixing SQLite correctness bugs!

Re: Bombadil: Property-based testing for web UIs

#77

Earlier quoted context omitted.

Did you have a look at the intro in the manual? https://antithesishq.github.io/bombadil/1-introduction.html If that's not clear, please let me know how we can improve it!

A hello-world example of what it looks like, and what running it would validate, would be nice. It's all very abstractly described in the README and that intro page you linked.

Fair enough! I'm probably doing a demo video that'd help with this. Maybe can condense that in text form into the readme as well.

Re: Bombadil: Property-based testing for web UIs

#78

From your title my immediate thought was "cool, maybe this will move us a bit closer to making components (or the testing thereof) cover accessibility thoroughly by default". See, the idea with the semantic web, and the ARIA markup equivalents, is that things should have names, roles, values, and states. Devs frequently mess up role/keyboard interaction agreement (example: role=menu means a list will drop on Enter ke…

Hey, sorry for antithesis.com. Thank you for noticing this!

The bug is subtle: we do have styles for that, but in some change which I probably did we use css variable, which isn't there...

We will fix that soon.

Re: Bombadil: Property-based testing for web UIs

#79
Timely! I spent a good chunk of yesterday investigating Bombadil. I'm a huge fan of PBT and a huge fan of temporal logic (though not linear temporal logic) and we're currently trying to level up our QA, so it seemed like a good match.

Unfortunately, I concluded that Bombadil is a toy. Not as in "Does some very nice things, but missing the features for enterprise adoption." I mean that in a very strong sense, as in: I could not figure out how to do anything real with it.

The place where this is most obvious is in its action generator type. You give it a function that generates actions, where each action is drawn from a small menu of choices like "scroll up this many pixel" or "click on this pixel." You cannot add new types of actions. If you want to click on a button, you need it to generate a sequence of actions to first scroll down enough, and then look up a pixel that's on that button.

Except that it selects actions randomly from your list, so you somehow need the action generator, when run the first time, to generate only the scroll action, and then have it, when run the second time, generate only the click action. If you are silly enough as to have an action generator that, you know, actually gives a list of reasonable actions, you'll get a tester that spends all its time going in circles clicking on the nav bar.

(Something in the docs claimed that actions are weighted, but I found nothing about an actual affordance for doing that. Having weights would make this go from basically impossible to somewhat impossible.)

(Edit: Found the weighted thing.)

I am terrified to imagine how to get Bombadil to fill out a form. At least that seems possible -- you can inspect the state of the web page to figure out what's already been filled out. But if you want the state to be based on anything not on the current page, like the action that you took on the previous page, or gasp the state on disk (as for an Electron app), that seems completely impossible. Action generators are based on the current state, and the state must be a pure function of the web page.

Its temporal logic has a cool time-bounded construct, but it's missing the U (until) operator. One of their few examples is "If you show the user a notification, it disappears within 5 seconds." But I want to say "When you click the Generate button, it says 'Generating...' up until it's finished generating." And I can't.

(Note: everything above is according to the docs. Hopefully everything I said is a limitation of the docs, not an actual limitation of the framework.)

I shared my comments with the author yesterday on LinkedIn, but he hasn't responded yet. Maybe I'll hear from him here.

I have a pretty positive opinion of Antithesis as a company and they seem to be investing seriously in it, and generally see it as a strong positive sign when someone knows what temporal logic is, so I have hopes for this framework. I am nonetheless disappointed that I can't use it now, especially because I was supposed to finish an internal GUI testing tool this week and my god I'm behind.

Re: Bombadil: Property-based testing for web UIs

#80
post #12
post #4

I'm a huge fan of property based testing, I've built some runners before, and I think it can be great for UI things too so very happy to see this coming around more. Something I couldn't see was how those examples actually work, there are no actions specified. Do they watch a user, default to randomly hitting the keyboard, neither and you need to specify some actions to take? What about rerunning things? Is there shr…

How effective is property based testing in practice? I would assume it has no trouble uncovering things like missing null checks or an inverted condition because you can cover edge cases like null, -1, 0, 1, 2^n - 1 with relatively few test cases and exhaustively test booleans. But beyond that, if I have a handful of integers, dates, or strings, then the state space is just enormous and it seems all but impossible to…

In practice I’ve found that property based testing has a very high ratio of value per effort of test written.

Ui tests like:

* if there is one or more items on the page one has focus

* if there is more than one then hitting tab changes focus

* if there is at least one, focusing on element x, hitting tab n times and then shift tab n times puts me back on the original element

* if there are n elements, n>0, hitting tab n times visits n unique elements

Are pretty clear and yet cover a remarkable range of issues. I had these for a ui library, which came with the start of “given a ui build with arbitrary calls to the api, those things remain true”

Now it’s rare it’d catch very specific edge cases, but it was hard to write something wrong accidentally and still pass the tests. They actually found a bug in the specification which was inconsistent.

I think they often can be easier to write than specific tests and clearer to read because they say what you actually are testing (a generic property, but you had to write a few explicit examples).

What you could add though is code coverage. If you don’t go through your extremely specific branch that’s a sign there may be a bug hiding there.

Post reply on HN