Starting browser sessions for a test suite.
This is the counterpart to Wallabidi.start_session/1, which is for an
application's own browser use. The two are separate because a project can
do both at once — the suite drives the app through a browser while the app
itself scrapes a supplier site — and they need different settings in the
same VM.
What this adds over Wallabidi.start_session/1:
- reads
config :wallabidi, :test(falling back to the application's settings for anything it doesn't set) - honours the
WALLABIDI_DRIVER/WALLABIDI_BROWSERenv pin, so a CI lane can route a whole run to one driver - resolves a driver from the test's capability tags (
@tag :browser,@tag :headless) when one isn't given explicitly
Wallabidi.Feature calls this for you, so a feature test needs nothing
extra. Use it directly when you start sessions by hand in a test:
{:ok, session} = Wallabidi.Test.start_session()Why not just Wallabidi.start_session/1?
It still works, and for a project whose only Wallabidi use is its test
suite it behaves the same. It's worth switching when the application
itself also drives a browser: only then do the two need to disagree about
base_url, max_wait_time and the rest.
Summary
Functions
The driver a test should run on.
A WALLABIDI_DRIVER / WALLABIDI_BROWSER env pin wins, so a pinned CI
lane routes every test to one driver regardless of its tags. Otherwise the
test's capability tag selects the cheapest driver that can satisfy it.
@spec start_session(keyword()) :: {:ok, Wallabidi.Session.t()} | {:error, term()}
Start a session for a test.
Accepts everything Wallabidi.start_session/1 does. Additionally:
:context— the ExUnit test context, used to resolve a driver from the test's capability tags.