Vibium for JAVA Selenium Framework

[VipinBorole7601]

Hi, I just want to know, can this Vibium be useful for a Selenium Java automation framework, and how?

[adrianrobinsondev]

Yes, though for us the payoff has come from somewhere other than writing tests.

Context

We run a large Java e-commerce app with a JUnit + Selenium 4 UI suite of a few thousand tests on Selenium Grid under Jenkins. Vibium went in mid-April 2026. Three and a half months later we have converted zero Selenium tests to Vibium and written zero new UI tests in it. It is still the most useful browser tool we picked up this year.

The reason: in a mature Selenium suite the bottleneck isn't writing tests, it's explaining them. Selenium hands you a TimeoutException, a stack trace, and a screenshot of a page that looks fine. It's a good executor and a poor instrument. What you need is to ask the live page questions, which is exactly the shape Vibium has.

The pattern: replay, don't rewrite

We built one agent skill (Claude Code) that takes a failing test name and:

1. Reads the Java test method, its setup, and the page objects it uses
2. Translates the @FindBy selectors and Selenium calls into Vibium commands
3. Steps them one at a time against a real host, screenshotting as it goes
4. Stops at the first divergence and reports expected vs. actual page state

The translation is deliberately boring:

Java / page object	Vibium
page object that auto-navigates	vibium go {host}{path}
@FindBy(id="x") + .click()	vibium click "#x"
.clear() + .sendKeys(v)	vibium fill "#x" "v"
wait.until(elementToBeClickable(...))	vibium wait "#x" --state visible

You don't port the test. You transpile it for one debugging session, then throw the transpilation away. The Selenium test stays the source of truth.

Two things mattered more than the translation itself. First, a compare-to <git-sha> mode that replays the old and new versions of a test side by side and reports the step where they diverge, so "it broke after that commit and the diff looks innocent" becomes a screenshot pair. Second, it stopped being a thing anyone decides to do: it's checked into the repo alongside our CI failure-retrieval skill and our test-triage agent, and both hand off to it on their own when a failure looks UI-shaped. Four skills and two agents in our tooling reach for Vibium now.

What it actually found

A failure whose cause wasn't in the code. A saved bill-of-materials test failed persistently, with a button that never enabled. Reading the source revealed nothing. The replay showed that before any test action the page already displayed an in-cart warning; the dialog then refused the edit with its own explanatory message, and the wait for it to close timed out. That timeout was the only thing Selenium had reported. Leftover cart state from a prior run.
One-line fix in setup. This is the category Vibium is good at: failures visible in the browser and invisible in the repository.

A real product bug hiding behind a flaky test. A checkout dialog test failed on 45% of first attempts, and the retry budget hid most of those as passes. Rather than lengthen the wait, we pointed Vibium at a standalone page with the real Bootstrap and our dialog markup, and fired the dismiss click at fixed offsets across nine timed trials:

dismiss at	Selenium sees visible	mid-transition	opacity	result
0 to 400ms	from ~150ms	yes	0 to 1	silently swallowed
451ms or later	yes	no	1	closes

Bootstrap's Modal.hide() returns early while the dialog is still transitioning, so a dismiss during the fade-in is discarded with no error and no retry. Selenium's visibility condition is satisfied ~300ms before the dismiss can possibly work, which made the test a coin flip decided by round-trip latency. Two findings that source reading doesn't give you: opacity is not a valid gate (it reaches 1 while the transition is still in progress, so "wait for opacity" ships a still-broken wait), and it's a genuine customer bug, because clicking the confirm button fast enough does nothing at all.

A "flaky" test that wasn't flaky. A made-to-length product configurator intermittently produced exactly half the expected line total. Everyone's read was a front-end reactivity race dropping a keystroke. Using Vibium we read the framework's live reactive state after each field entry, then hooked the page's own HTTP client to capture the outgoing request before submitting: state correct, payload correct, server correct. The cause was a test-data schema difference producing a unit price exactly half of what the test expected. Generalizable: a "flaky" value that is always wrong by the same exact factor is a data problem, not a timing problem, and reading the live payload settles it in minutes.

Two things with nothing to do with tests. (a) A customer-reported checkout problem came with a console error attributed to our page. Loading that URL in a clean extension-free browser under Vibium with error hooks, and sitting on it, produced zero errors. The message belonged to a browser extension, whose content scripts Chrome attributes to the page. False lead closed. (b) Pre-deploy, we drive a candidate build and the live site with the same commands to measure a feature delta. On a product-reviews overhaul, review counts dropped on the candidate, and Vibium made "intentional dedup vs. data loss" answerable rather than arguable.

Why the CLI shape is what makes this work

Here is the telling part. The packaged replay workflow gets invoked a handful of times a month, but the raw CLI gets called hundreds of times, because an agent mid-hypothesis reaches for vibium eval the way you would reach for a REPL. Across the sessions I still have logs for, eval accounted for roughly five times as many invocations as click and fill combined. We use Vibium overwhelmingly to observe, not to drive. One command per action, plain text out, no session boilerplate, and a daemon that keeps the browser alive between calls. That is what lets an agent iterate a hypothesis in a loop. A programmatic binding needs a compile step per hypothesis; the CLI doesn't.

Reading live front-end framework state through eval is the single highest-leverage trick. It's the difference between measuring a client-rendered value and inferring it from source, and inference is what produces confidently-wrong triage.

A note on the "modern websites" argument

Plenty of teams are moving to Playwright on the premise that it handles modern front ends better. Worth describing what our front end actually is, because it's the case that premise tends to skip. A long-lived enterprise app is not
one stack.
Pages written a decade ago are still in production and still earning revenue.

Selenium has driven that mix without complaint. The UI failures we have actually diagnosed came down to fixture pollution, test data drift, and library-level timing behavior. The one genuinely framework-related failure was a real bug in our own code, which Selenium caught correctly. That is a very different thing from a driver that can't handle reactive components.

The dialog race above is the sharpest example. It looked exactly like the sort of "modern page" problem teams switch tools over, and the cause was a Bootstrap transition guard silently discarding a call. No driver would have fixed that. Better observability did.

We also got the capability most often cited as a reason to leave, without leaving: Selenium 4's own BiDi network interception let us mock a response and turn a data-starved test deterministic, on the same Grid, inside the existing suite.

And BiDi is why Vibium composes with what we already run instead of competing with it. Both speak the same standard protocol, so Vibium can attach to an existing session on the same Grid our Selenium suite runs on, which we proved out end to end. That makes it a companion rather than a migration. For a team with a large existing Java suite, "add an instrument" is a far cheaper proposition than "replace the executor," and an open protocol plus open source is what makes that option exist at all.

What I'd suggest

Keep Selenium as the regression suite for now. It is your CI gate, and porting it buys nothing right now. Add Vibium as the diagnostic layer beside it, agent-driven, aimed at what Selenium can't answer: a flake nobody can explain, a test that only fails in CI, "it broke after this commit and the diff looks innocent," verifying a fix without paying for a suite run, and pre-deploy exploratory passes.

After three and a half months: Vibium hasn't written us a single test for our regression suite and has paid for itself many times over anyway. I do have Vibium tests on a working branch that I will evaluate against Selenium counterparts once Grid support reaches a release (soon). Local runs are promising though and once Grid support is confirmed, I'll begin a full evaluation of comparing our most complicated Selenium tests to a ported Vibium version.

The goal is to eventually write all new tests in Vibium. The beauty of open source software built against a standard (WebDriver BiDi) is that Selenium and Vibium can work side-by-side. This is way better than the idea of feeling forced to port an established test suite to a hot new tool just for the sake of adopting the new tool.

We did the same exercise porting from JUnit 4 to JUnit 5. Legacy JUnit 4 tests ran side-by-side with JUnit 5. Today we are 100% on JUnit 6 (with the help of AI doing the heavy lifting). That means the vast majority of human effort was spent on being productive building and testing for new features rather than spending that time migrating from one technology to another without significant net gain for the operation.

There's no real incentive I see in porting Selenium tests to a different technology whether Playwright or Vibium. There is great incentive to adopting Vibium into your tech stack on its own merits, especially when adopting AI in your Quality Engineering practice. Porting Selenium to Vibium is a lower priority effort that you do when you have the spare resources because you don't have to port over to benefit from using Vibium and that's the point. That could change once a Vibium native feature comes along that you find invaluable and goes unsatisfied by Selenium. Comfortably cross that bridge when you get to it.

Most of the AI-tooling value in a mature QA/DevOps setup turns out to be observability and diagnosis rather than code generation, and a browser an agent can interrogate one command at a time fits that far better than one it has to program.

[hugs]

thank you for this experience report!!!!!