GitHub

tester-army/e2e Agentic UI Testing

How bounded agent paths become inspectable test evidence

10 chapters100 min total
Keywords
tester-army/e2eTestingAgentsSemanticsLocatorsAssertionsReplayPrivacyCIMobile
Overview

This series examines tester-army/e2e as a runner and engine system for web and mobile end-to-end tests, not merely a model that clicks through a UI. It follows the path from semantic observation and one-goal bounded execution to exact postconditions, browser/mobile capability boundaries, replay, secret-safe evidence, CI operations, and adoption decisions. Its central thesis is bounded semantic control: agents can choose among current UI paths, while the runner validates actions, waits for settled state, classifies failure, protects evidence, and leaves verdicts to deterministic checks or narrowly justified judgments. The repository supports this architecture and concrete limits, but does not establish universal autonomy, lower cost, or better defect detection; teams must measure those locally.

Learning outcomes
  • tester-army/e2e is a runner-and-engine system: the agent chooses a path, while the runner controls capabilities, budgets, settling, privacy, and verdicts.
  • Use exact screen and expect checks for known values, counts, routes, or states; use model judgment only for genuinely interpretive visible questions.
  • Replay can save model calls only when targets relocate unambiguously and the replay itself produces the recorded state change; assertions still run fresh.
  • Trust agentic coverage conditionally: the app needs a clear semantic surface, the engine and evidence policy must fit, and teams must validate claims locally in CI.
Keywords
tester-army/e2eTestingAgentsSemanticsLocatorsAssertionsReplayPrivacyCIMobile

Chapters

Preview every chapter · Unlock full text, audio, and video from chapter 4

Plans
Ch.1-3 FreeCh.4-10 Premium

FAQ

What is tester-army/e2e designed to prove?

tester-army/e2e is designed to prove that a bounded path through a web or mobile UI reached a visible, testable outcome, not merely that a model described success. It combines semantic observations, authorized actions, settling, and exact or bounded checks.

When should a test use an agent instead of deterministic actions?

Use an agent when the UI path is variable but the outcome can be stated and checked clearly. Keep deterministic actions for exact interactions or high-risk or irreversible steps, and use a hybrid when only navigation needs flexibility.

Can tester-army/e2e replay agent actions safely?

It can replay a verified trace conditionally, not as a blind macro. It rechecks context, relocates targets, requires evidence of a meaningful state change, and hands control back or fails on ambiguity, stale assumptions, or uncertain commits.

How does tester-army/e2e handle secrets and screenshots?

tester-army/e2e keeps secrets behind opaque handles, authorizes their sinks, redacts textual evidence, and taints the attempt after sensitive input so pixels may be withheld. Non-secret semantic assertions can still prove the result, but external providers and app logs remain outside this guarantee.