A resilient test is not one that ignores change. It is one that survives changes that do not matter and calls attention to changes that do.
Traditional end-to-end tests often mix product intent with implementation detail. A test that should mean “a customer can update their profile” can become a sequence of CSS selectors, element positions, button labels, and timing assumptions. Once those details are embedded in the test, harmless UI work starts looking like product failure.
Testronaut missions can stay closer to the user journey. The agent sees the current page and decides how to carry out the objective, so the author can spend less time describing the DOM and more time defining what success actually means.
Start with a single outcome
A good mission has a clear center of gravity. “Create a project and verify it appears in the project list” is a useful objective. “Log in, create a project, invite three people, change billing, export a report, and then delete everything” is a small test suite disguised as one paragraph.
Smaller missions make failures easier to understand, control token usage, and let useful journeys be combined in different suites. They also force the author to identify which outcome is important enough to verify.
Describe the interface like a user
Prefer durable concepts such as “open account settings,” “choose the annual plan,” or “submit the support request.” Avoid instructions such as “click the third button,” “find div:nth-child(2),” or “use #submit-button-47.”
This does not mean labels are forbidden. Visible names are often how users understand a control, and mentioning a label can remove ambiguity. The distinction is whether the instruction communicates meaning or leaks an implementation detail.
Goal:
Create a project named Apollo Demo.
Steps:
1. Open the Projects area.
2. Create the project using the default settings.
3. Return to the project list.
Validate:
- Apollo Demo appears in the project list.
- The project can be opened successfully.Make success observable
Completing an action is not the same as verifying its effect. “Click Save” only describes an interaction. The mission should say what the application must show afterward: the updated value remains after navigation, a new record appears in the list, or the correct status is visible.
Good validations give the agent an explicit stopping condition. They also make the report useful to a person who was not present when the mission was written.
- Name the business outcome, not merely the final click.
- Verify persistent state when persistence is the feature under test.
- Use exact expected values when correctness depends on them.
- Capture evidence at the point where success is visible.
Provide context without scripting the route
The agent cannot infer facts that are not in the interface. Tell it which test account or record to use, where a journey should begin, and which conditions are acceptable. If an onboarding modal may appear, say that it can be dismissed. If an existing fixture must never be edited, say that too.
Context establishes guardrails. It should not become a screenplay. Leave ordinary navigation and interaction choices to the agent unless a particular route is itself what the mission is testing.
Control data and side effects
Flexible navigation does not excuse ambiguous test data. Use recognizable, isolated names for created records. Decide whether a mission may reuse existing data or must create its own. Include cleanup when repeated runs would otherwise interfere with one another.
Be especially direct around destructive or externally visible actions. A mission that can send email, charge a payment method, delete records, or invite real users needs tighter boundaries than one that reads a dashboard.
Do not hide every unexpected state
Resilience is valuable when the interface changes but the journey remains valid. It is dangerous when a mission is so permissive that it works around a defect and reports an ordinary pass.
Anticipated variations belong in the mission. Unexpected recoveries belong in the report. If a normal user would not be expected to refresh a broken page, retry an action repeatedly, or sign in again halfway through a journey, the test should preserve that fact even if the agent eventually succeeds.
A review checklist
- Can the mission objective be summarized in one sentence?
- Are the instructions written in user-facing language?
- Does the mission define observable success?
- Are required accounts, fixtures, and constraints supplied?
- Could the mission run repeatedly without corrupting shared data?
- Would an unexpected workaround remain visible in the result?
Minimal-selector authoring is not about making missions vague. It is about being precise at the right level: precise about intent, data, boundaries, and expected outcomes; flexible about incidental markup and the route through the interface.