What Testsnag is, and the words it uses

The core vocabulary: test, step, assertion, run, suite, and block. Worth five minutes before anything else.

View as Markdown

Testsnag watches the parts of your product that must not break. You describe a journey once, usually by recording yourself doing it, and Testsnag replays that journey against your live site on a schedule, on a deploy, or whenever you ask. When something breaks, you find out from Testsnag rather than from a customer.

  1. 1A test: one journey you want verified, named after the journey rather than the page.
  2. 2Steps: the ordered actions that make up the journey.
  3. 3An assertion: the step that checks the journey actually worked.
  4. 4Build steps by clicking through a live browser, describing them to the AI, or adding them by hand.

The six words worth knowing

Most of the interface is built out of six ideas. They nest inside each other, and once the nesting is clear the rest of the product tends to explain itself.

  • Test: one journey you want verified, such as "checkout as a guest". A test holds an ordered list of steps and lives independently of every other test.
  • Step: a single action inside a test: click this, type that, go here, wait for this. Steps run in order, top to bottom.
  • Assertion: a step that checks rather than acts. "The heading now reads Thanks for your order." Without assertions a test only proves that clicking did not crash.
  • Run: one execution of a test, with a pass or fail result, timings, screenshots, and logs. A test is the question; a run is the answer.
  • Suite: a named group of tests that run together as a unit, with their own schedule and notifications.
  • Block: a reusable group of steps, like a login sequence, that you write once and drop into many tests.

What a good test looks like

A good test is narrow, named after the journey rather than the page, and full of assertions. "Checkout, guest user" that clicks through five pages and asserts the order confirmation number appears is worth more than a broad test that visits twenty pages and asserts nothing. Narrow tests also fail usefully: when one goes red you know immediately which journey is broken.

A test that clicks through a flow without asserting anything will keep passing even after the flow silently breaks. Assertions are the part that makes a test worth running.

Where to go next

If you have not built anything yet, your first test walks the whole loop end to end. If you would rather understand the recorder first, start with the Cloud Recorder.

Still stuck, or spotted something out of date?

Contact support