Test dependencies
A test script rarely runs alone. It needs an API key, a backend that is not built yet, an app that runs on your laptop, or real browsers. Test dependencies let you declare those needs on the test’s Dependencies tab. Every run then starts with a preparing dependencies phase that brings up what is stopped, injects the addresses as environment variables, fails with a named reason when something cannot come up, and releases what it started when the run ends.
The five kinds
Section titled “The five kinds”| Kind | What the script gets | Run lease |
|---|---|---|
| Secret | An encrypted workspace value | No. Injected, never leased. |
| Virtual service | The URL of a mocked backend | Yes. Started if stopped. |
| Tunnel | A public URL for an app on your machine | Yes. Never stopped by a run. |
| Browser fleet | Endpoints and a token for managed real browsers | Yes. Started, then stopped after the run. |
| Data | A CSV or generated dataset, one row per virtual user | No. A read-only summary row. |
The variables a script reads, one per line:
SECRET_<NAME>MAXOPERF_VS_<STEM>_URLMAXOPERF_TUNNEL_<STEM>_URLMAXOPERF_FLEET_<STEM>_WEBDRIVER_URLMAXOPERF_FLEET_<STEM>_PLAYWRIGHT_URLMAXOPERF_FLEET_<STEM>_CDP_URLMAXOPERF_FLEET_<STEM>_TOKENA dataset has no variable. It is bound per virtual user and read from the Data tab.
<STEM> is the name you choose when you bind the dependency: upper-case letters, digits and
underscores, starting with a letter, at most 40 characters. A virtual service bound as PAYMENTS is
injected as MAXOPERF_VS_PAYMENTS_URL. The binding dialog shows the exact name before you save.
A lease is the run’s claim on a dependency. Only virtual services, tunnels and browser fleets get one, because only those have a state the run has to wait for. A secret has nothing to wait for. A dataset is delivered by the Data tab, not by the preparing phase.
Wiring at a glance
Section titled “Wiring at a glance”- Create the dependency once, in its own product: a secret in the vault, a virtual service, a tunnel, a browser fleet or a dataset.
- Open the test, go to Dependencies, click Add dependency, pick the kind and the entity, and choose a stem. Datasets are bound on the Data tab and appear here as a read-only row.
- Read the injected variable in the script, or pick the dependency as a chip in a builder field.
- Start the run. MaxoPerf prepares every lease, then starts the runners with the variables set.
- When the run ends, MaxoPerf releases the leases and stops only what the run started.
Run-time behavior covers steps 4 and 5 in detail. The worked example wires one checkout test to all five kinds.
When to use which
Section titled “When to use which”| Your test needs | Bind | Leave it out when |
|---|---|---|
| A credential the script must not contain | A secret | The value is public and the same for everyone. |
| A third-party or unfinished API that is slow, costly or absent | A virtual service | The real service is cheap, stable and safe to hit under load. |
| An app on your laptop or a private network | A tunnel | The app already has a public URL. |
| Real Chrome, Firefox or Edge for a script | A browser fleet | The test is an API test, or MaxoPerf’s own browser tests are enough. |
| Different input for each virtual user | A dataset | Every virtual user sends the same request. |
Data and the EUX probe
Section titled “Data and the EUX probe”A dataset is the fifth kind, but it is bound on the test’s Data tab, per virtual user, and is not a lease. The Dependencies tab lists it as a read-only row that links back to the Data tab. See Test data for splitting rows across runners.
An EUX probe is a browser test that runs next to a load test to measure real browser experience under load. A run with a probe is a composite run. The test’s own dependencies and the master test’s dependencies reach every member run, and the run’s Dependencies tab shows which member needed which lease. Run-time behavior explains which value wins when both define the same name.