Assertions on every step, and the questions tests rarely ask

Step checks

Every request, sign-in and refresh step can carry checks:

• Status: “is 200”, or “is 403” for a step that must be refused.
• Response time: “within 500 ms”.
• Response fields: total equals 2, items[0].status is not "pending", items has more than 0 entries, id exists.

Without a status check, any 4xx or 5xx fails the step; with one, the check decides, so denials become testable. After a run each check shows pass or fail and the actual value.

Access audit

Every role from your flows signs in and probes every endpoint, along with a caller without a token:

• with its own ids, which should work if the role may do this;
• with ids only other roles can see, which should be refused (insecure direct object references, cross-tenant reads, updates and deletes);
• with writes that point at another tenant, which should be refused;
• with lists, which must only return the role’s own tenant;
• without a token, which should answer 401.

Findings are ranked: critical for cross-tenant access or a scoped role that sees everything, high for endpoints open without login or allowed against the policy, and “needs a decision” for writes no flow describes. Decisions become the project’s access policy, which the mock enforces. On the mock, data is restored after every probe; on live environments the audit never sends delete probes and only probes writes where writes are allowed.

Load tests

Repeat one step of a flow many times with a number of requests in flight. The steps before it run once to sign in and collect ids; throughput and p95 stream live. Afterwards it checks:

• error rate and p95 against your limits;
• that the collection grew by exactly the number of successful creates;
• that no record points at a missing one;
• that a scoped role only wrote inside its scope;
• that the whole flow still passes.

Comparing environments

“Compare with…” on a finished run puts it next to the newest finished run of the same flow on another environment or the mock, step by step: status, time, status code, failed checks, and fields only one reply has or whose type differs.

Verified domains

Load tests and audits send many requests, writes and cross-tenant probes, so on this installation they only run against environments on a domain your project has verified, by a DNS TXT record or a file on the domain. Nobody can aim them at someone else’s API. Flow runs and monitors don’t need it: they make the few requests a user would.