pinetops
Wallabidi - Concurrent browser testing for Elixir over WebDriver BiDi/CDP, a fork of Wallaby
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
Most Liked
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 ![]()
![]()
![]()
Popular in Announcing
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #hex










