How to Parallelize Vibium Tests

To parallelize Vibium tests, run them with pytest -n auto (the pytest-xdist plugin) and give each test its own isolated browser or context, so workers never share state. Vibium browsers and contexts are fully isolated — each has its own cookies, storage, and page state — which makes them a clean fit for parallel execution: launch one headless browser per worker, run, and tear down. Because browser tests are dominated by network and rendering I/O, concurrency yields near-linear speedups; a suite that takes ten minutes serially can finish in a fraction of that across eight workers. The golden rule is one browser (or one context) per test, never a shared instance, because two workers driving the same page would race over its state. Vibium's single Go binary auto-downloads Chrome once and reuses it, so spinning up many browsers stays cheap. The only real ceiling is memory, since each headless Chrome is a real process.

How do I run Vibium tests in parallel with pytest?

Install pytest-xdist and run with -n auto to spread tests across worker processes equal to your CPU count. As long as each test gets its own browser, this is all you need.

pip install pytest-xdist
pytest -n auto        # one worker per CPU core
pytest -n 8           # or pin an explicit worker count

xdist forks worker processes, and each test runs in exactly one worker, so a per-test browser fixture is automatically isolated per worker. There is no special Vibium configuration — the isolation comes from giving each test its own browser instance, which the fixture below handles.

What does a parallel-safe browser fixture look like?

Make the browser fixture function-scoped so every test launches and quits its own browser. This guarantees no two concurrently running tests ever touch the same page.

# conftest.py
import os
import pytest
from vibium import browser_sync as browser
 
 
@pytest.fixture
def vibe():
    instance = browser.launch(headless=os.getenv("HEADLESS", "true") == "true")
    try:
        yield instance
    finally:
        instance.quit()

Each test that requests vibe gets a fresh, isolated browser, and the try/finally ensures quit() runs even on failure so workers never leak Chrome processes. This is the simplest parallel-safe setup and the right default for most suites.

Can I reuse one browser with a context per test?

Yes — for faster startup, launch one browser per worker and create a fresh context per test. Each Vibium context has its own cookies and storage, so tests stay isolated while sharing a single browser process. This trades a little fixture complexity for skipping a full launch on every test.

@pytest.fixture(scope="session")
def shared_browser():
    instance = browser.launch(headless=True)
    yield instance
    instance.quit()
 
 
@pytest.fixture
def vibe(shared_browser):
    ctx = shared_browser.new_context()   # isolated cookies/storage
    page = ctx.new_page()
    yield page
    ctx.close()

With xdist, each worker gets its own shared_browser (fixtures are per-worker), and within a worker each test gets a clean context. You get parallelism across workers and isolation within them, at lower per-test overhead than launching a browser every time.

How many workers should I run?

Start at your CPU core count and tune by watching memory, because each headless Chrome uses a few hundred megabytes and RAM is usually the ceiling, not CPU. A practical heuristic:

• 4–8 workers on a typical CI runner or a 16 GB laptop.
• More on a big machine — divide available memory by ~400 MB per browser and leave headroom.
• Back off if swapping — if the box starts paging to disk, drop the worker count; a swapping machine is slower than fewer workers.

pytest -n auto is a sensible starting point, but on memory-constrained CI an explicit -n 4 often beats auto because it avoids over-subscribing RAM. The same one-browser-per-task math applies whether you are testing or scraping in parallel.

Why must each test have its own browser or context?

A Vibium browser holds a single page's state — current URL, focused element, session cookies. If two parallel tests drive the same browser, one test's go() yanks the page out from under the other, producing race conditions that look like random flakiness. Launching a fresh browser per test, or a fresh context per test, keeps each one fully independent and immune to that cross-talk. This isolation is exactly why Vibium parallelizes cleanly: there is no global state to coordinate, just independent sessions. For the architecture that makes many concurrent browsers affordable, see how Vibium works.

How does parallelization fit into CI?

Parallel runs pay off most in CI, where shaving minutes off every push compounds across a team. Add -n auto to the test command in your GitHub Actions workflow and the runner spreads tests across its cores automatically. Pair it with caching Chrome for Testing so workers do not each re-download the browser, and your pipeline stays fast even as the suite grows from dozens to hundreds of tests. The combination — isolated per-test browsers plus xdist plus a cached Chrome — is the standard recipe for a quick, reliable Vibium pipeline.

Next steps

• Running Vibium in CI/CD with GitHub Actions
• How to Structure a Vibium Test Suite
• How to Parallelize Scraping with Vibium