TesterArmy e2e
TesterArmy e2e architecture: observe, act, assert, record
Trace how a semantic step and a conventional assertion meet in the runner
What you will learn
- Separate the layers
- Follow action decisions
- Place replay after verification
Before you start
- A disposable app or test account
- A web or mobile engine
- A deliberate model-provider choice for agent steps
Use two runs and one controlled UI mutation before trusting cached actions
Key takeaways
- Runner and engine are separate components.
- Adaptive and locator checks have different roles.
- Replay needs a valid end-state check.
Separate the layers
The runner selects a target and engine, opens the app, and executes test fixtures. The engine provides observations and supported actions. The agent executor decides what to do with those observations during an adaptive step.
`agent.act` and `agent.assert` are not the same as a locator assertion. The first two can ask a model for actions or judgments; the last checks a specified element through the test API.
Follow action decisions
The pinned `act.ts` and executor source show an agent step moving through observations, tool choices, actions and completion checks. The decision-model package offers an alternative bounded decision route with its own gates.
A model saying a goal is complete is not enough for every test. Pair an adaptive step with a stable assertion when the app exposes a reliable DOM or native accessibility element.
Place replay after verification
A trace recorder stores a replayable action sequence when the step has a suitable verified end state. `replay.ts` then tries those actions under the same step limits and checks the live screen.
If a target moves or the end state fails, the replayed prefix stops. That protects against blindly treating old coordinates as proof of a new app state, although only an executed test can establish reliability.
Decision guide
| Criterion | Option A | Option B |
|---|---|---|
| Best when | You need predictable behavior and easy auditing | You need adaptive optimization and have reliable telemetry |
| Main risk | May leave performance on the table | Can become difficult to explain or debug |
Implementation steps
- 1
Identify the target, engine and fixture.
- 2
Follow observation, action and assertion separately.
- 3
Inspect why a trace was recorded or rejected.
Copy-ready example
runner -> target engine -> observation
observation -> agent action -> app
app -> assertion -> trace recorder
next run -> conditional replay -> end-state checkFrequently asked questions
Does the model always decide whether the test passes?
No. Tests can use explicit locator assertions, and the first quickstart example needs no model.
Does replay blindly click saved coordinates?
The pinned replay source includes target relocation, step limits and an end-state verification path.
Sources
- TesterArmy e2e / docs/quickstart.mdxSource checked 2026-10-14
- TesterArmy e2e / docs/reference/runner.mdxSource checked 2026-10-14
- TesterArmy e2e / docs/reference/engine.mdxSource checked 2026-10-14
- TesterArmy e2e / packages/e2e/src/agent/act.tsSource checked 2026-10-14
- TesterArmy e2e / packages/e2e/src/agent/executor.tsSource checked 2026-10-14
- TesterArmy e2e / packages/e2e/src/agent/replay.tsSource checked 2026-10-14
- TesterArmy e2e / packages/e2e/src/cache/recorder.tsSource checked 2026-10-14
- TesterArmy e2e / packages/e2e/src/run/runner.tsSource checked 2026-10-14