Reads Wallabidi settings, keeping the test suite's configuration separate from the application's.
A project can use Wallabidi in two unrelated ways at once: its test suite
drives the app through a browser, and the app itself drives a browser as
part of what it does (scraping a supplier site, rendering a PDF). Both run
in the same VM under mix test, and both used to read one flat
config :wallabidi — so the suite's base_url and max_wait_time would
silently govern the application's sessions.
Settings therefore live in two places:
# the application's own browser use — read by Wallabidi.start_session/1
config :wallabidi,
driver: :lightpanda,
base_url: "https://supplier.example.com",
max_wait_time: 10_000
# the test suite's — read by Wallabidi.Test.start_session/1
config :wallabidi, :test,
driver: :chrome_cdp,
base_url: "http://localhost:4002",
max_wait_time: 3_000config :wallabidi, :test falls back to the top-level value for any key it
doesn't set, so existing single-namespace projects keep working unchanged.
Summary
Functions
Fetch key for the application's own Wallabidi use.
Fetch key for whichever mode the calling session belongs to.
Fetch key for the test suite, falling back to the application-level
value when config :wallabidi, :test doesn't set it.
The raw config :wallabidi, :test keyword list.
Functions
Fetch key for the application's own Wallabidi use.
@spec get_for(Wallabidi.Session.t() | nil, atom(), term()) :: term()
Fetch key for whichever mode the calling session belongs to.
Sessions started by Wallabidi.Test.start_session/1 are flagged, so
reads made while driving them (visit/2's base URL, the auto-wait
budget) resolve against the test namespace; everything else resolves
against the application's.
Fetch key for the test suite, falling back to the application-level
value when config :wallabidi, :test doesn't set it.
@spec test_config() :: keyword()
The raw config :wallabidi, :test keyword list.