Wallabidi is a concurrent browser testing for Elixir. You write a test once and it runs on the cheapest driver that supports it — from an in-process LiveView render up to a full real browser — in a single mix test run.
It’s a fork of Wallaby, whose Browser/Query/Element/Feature/DSL APIs it keeps close to (migration is largely a find-and-replace). Wallaby is excellent; we forked because the changes we wanted — replacing the whole transport layer, dropping Selenium and the HTTP-polling model, and adding LiveView-aware waiting — were too invasive to land upstream without breaking existing users.
Four drivers, one suite:
Liveview (In-process via Phoenix.ConnTest, no browser) - runs untagged tests
Lightpanda (Headless JS browser over CDP) - runs @tag :headless
Chrome (BiDi) (Full browser via WebDriver Bidi) - not used by default
Each test declares its minimum capability with a tag; wallabidi routes it to the cheapest driver that satisfies it, with sensible zero-config defaults. No chromedriver, no Selenium server — drivers are spoken to directly over WebSocket.
What’s different from Wallaby:
LiveView-aware waiting on every interaction. visit, click, fill_in, and assert_has automatically wait for the right thing — the LiveSocket to connect, the DOM patch to land, the async update to arrive — by hooking LiveView’s onPatchEnd
and a MutationObserver, never polling. No manual sleep/retry loops.
Direct CDP/BiDi transport over WebSocket — event-driven log/error capture, request interception, lower latency, no chromedriver process to manage.
Test isolation built in. Integrates with sandbox_case and sandbox_shim to propagate Ecto/Cachex/FunWithFlags/Mimic/Mox sandboxes to every server-side process a browser triggers — across all remote drivers.
Removed: the Selenium driver and the HTTPoison/Hackney dependency stack.
Concurrency. LiveView, Lightpanda, and Chrome CDP all run well at ExUnit’s default --max-cases; only the BiDi driver currently benefits from a cap (–max-cases 8).
Requires Elixir 1.18+, OTP 28+. Firefox via GeckoDriver is architecturally possible (it also speaks BiDi) but not yet implemented. If you need the Selenium/Java server, stay on Wallaby.
I noticed in your docs that I am being credited as the creator of Wallaby. I’d like to clarify that I am just the current maintainer, but not the creator.
I want you to know that I have thought about how nice it would be to have a DSL that was able to run behaviour driven development specifications in live view or wallaby. I’ll tell you about my use case.
I’m writing a Phoenix live view focussed development harness.
I use the excellent sexy specs BDD library.
I had a lot of tension around whether to make the test I write use the live view test, abstractions, or the Walloby abstractions by default
I landed on the live view test abstractions because using Walloby for everything would mean that my tests were slow by default.
However, my dreamboat situation is that my live view tests could be executed against a UAT instance.
My harness will generate a full journey test, which essentially tests all the main use cases of the application in one fell swoop. I always thought it would be really rad to be able to run that as a live view test as part of my BDD suite, and also execute it in Walloby against my UAT instance as a go/no go before automated production deploys.
That sounds really great. Maybe you would find the driver layer of Wallabidi helpful. As far as performance, liveview is definitely fastest. But lightpanda is really fast too. Maybe fast enough that it’s not worth worrying about.
I did a fair amount of optimization. It tries very hard to reduce the number of roundtrips, so multiple instructions in the API translate into a set of opcodes and handled in a single round trip.
And the big thing is that it really does work at maximum concurrency. The starting point for this was being annoyed at having to disable async tests to get them working reliably. Wallabidi plus the supporting tools makes it much easier to max out your CPUs.
I have been following your releases on hex for a little bit after I found it accidentally when checking that the docs rendered properly for bibbidi.
I have a version 0.4 of bibbidi coming out and a higher level bobbidi library and am planning to get an adapter built for wallabidi mainly to test the interface and process reaping.
