reticle_assert is the second of the two tools that produce a verdict. It takes the same predicate grammar as reticle_act_and_wait and evaluates it against what already happened.
A real failure
Failures are more instructive than passes, so here is one. I asserted a route change to / on a page that was already at /:
Read assertion: "route.changed" carefully. The route predicate asserts that the route
changed, not that it currently equals a value. Asserting the route you are already on will
always fail. This catches people out, and the response says so in expected rather than leaving
you to work it out.
expected and observed side by side. A verdict that says only “failed” makes you go digging; this one tells you what it wanted, what it saw, and where in your source the relevant element lives.
Arguments
Scope it with since
Without since, an assertion evaluates against the recent buffer, which may contain events from before your action. That can pass for the wrong reason. The request you are asserting fired, but it fired two clicks ago.
The cursor comes from the preceding reticle_act response. Use it whenever you are asserting something an action was supposed to cause.
When to use assert over act_and_wait
Use reticle_act_and_wait when you are performing the action. Use reticle_assert when:
- you are checking a precondition before acting;
- the state was reached by several actions and you want one verdict over the lot;
- you want to assert something extra about an action you already ran, using its
since cursor.
verified: "unknown" means Reticle could not tell. It is not a pass, and it is not a failure, it
is a statement that the evidence was insufficient. Report it as unknown rather than rounding it in
either direction.
