TesterArmy e2e
TesterArmy e2e source-code map: from test call to trace replay
Locate the files that implement adaptive steps, recording and runner control
What you will learn
- Begin at public calls
- Read the recording boundary
- Find the model loop
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
- Recording has non-replayable cases.
- Replay checks live conditions.
- The API is still evolving.
Begin at public calls
The README’s example combines `agent.act`, `agent.assert` and `expect`. `packages/e2e/src/agent/act.ts` handles a semantic action request while `run/runner.ts` manages suite execution and target lifecycle.
Do not infer behavior from the natural-language test line alone. Match the requested step to the configured engine and the actual action grammar it exposes.
Read the recording boundary
`cache/recorder.ts` creates a trace from accepted actions and marks certain unsafe or incomplete inputs non-replayable. Its comments explain why a value cannot simply be trimmed or a missing action silently ignored.
`agent/replay.ts` binds recorded actions to live executor operations. It checks viewport and target conditions, stops on mismatch, and verifies the end state before a trace can self-finalize a step.
Find the model loop
`agent/executor.ts` and `agent/tool-loop.ts` manage adaptive execution. The runner and engine interfaces separate test orchestration from browser or device implementation.
These file relationships are source inspection, not a claim that all failure paths were executed. Pin the revision when tracing a behavior because the repository marks its API as still changing before 1.0.
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
Start with the public test call.
- 2
Trace runner, executor, recorder and replay.
- 3
Test one mismatch rather than assuming the happy path.
Copy-ready example
test call -> runner.ts -> act.ts -> executor.ts
accepted actions -> recorder.ts -> trace
next run -> replay.ts -> live end-state checkFrequently asked questions
Which file stores replay input?
The pinned cache/recorder.ts builds a trace from action records.
Where is a replay attempted?
The pinned agent/replay.ts applies the trace to the current observed screen.
Sources
- TesterArmy e2e / README.mdSource 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/run/runner.tsSource checked 2026-10-14
- TesterArmy e2e / packages/e2e/src/cache/recorder.tsSource checked 2026-10-14
- TesterArmy e2e / packages/e2e/src/agent/replay.tsSource checked 2026-10-14