Some things cannot be established by reading code. Whether a form submits, whether a flow completes, whether a page renders — these need the application running and something using it.
Browser tests are how Coroid checks them. Find them under Quality → Tests → Browser.
Scenarios
A scenario describes a user flow in plain language: what to do, and what should be true afterwards.
Sign in as a standard user, open the billing page, and change the
plan from Free to Professional.
Expect: the confirmation dialog lists the new monthly price, and after
confirming, the plan shown in the header is Professional.Write expectations as observable outcomes. "The page works" cannot fail meaningfully; "the header shows Professional" can.
Test targets and accounts
A test target is the environment a scenario runs against — usually a preview of the change being verified.
Targets carry their own configuration and test accounts. Test accounts are credentials that exist for this purpose.
Gating on results
Browser test results can feed a quality gate like any other check — blocking or advisory.
Advisory is the right default here for longer than elsewhere. Browser tests are the flakiest class of check in any system: they depend on timing, network and a live environment. Make them blocking only once you have watched a particular scenario be stable across many runs.
Keeping them useful
- Few and important. Ten scenarios covering critical flows beat a hundred covering everything. Each one costs time on every run.
- Independent. A scenario that depends on another having run first fails in confusing ways.
- Clean up. A scenario creating data should not leave state that breaks the next run.
When a scenario fails
Check the evidence before the code. Browser runs capture what happened, and the most common causes are environmental — the preview was not ready, a dependency was down, an account was locked.
A genuine failure will reproduce. A flake will not.