pinetops
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 (CDP) (Full browser via Chrome DevTools Protocol) - @tag :browser
- 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.
Docs: wallabidi v0.4.1 — Documentation
Hex: wallabidi | Hex
Where Next?
Trending in Announcing
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Supporting innovation across the BEAM ecosystem.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #ai
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #elixirconf-eu
- #metaprogramming
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Bringing learning, work and compliance together since 1987.
Producing high quality Elixir screencasts since 2017.
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 6- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
mhanberg
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.
pinetops
Thanks. I’ll update in the next version.
johns10davenport
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.
pinetops
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.
felix-starman
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.
I’m excited to see wallabidi progress
Graborg
Looking forward to trying this out!
I’ve been using GitHub - germsvel/phoenix_test: PhoenixTest provides a unified way of writing feature tests -- regardless of whether you're testing LiveView pages or static (non-LiveView) pages. · GitHub from before and find that it helps between the live view / dead view separation. Have you got any plans to include that in your package?