Designing a good test

Write workflows that read like a person, stay reliable, and fail with clarity.

A Canary test is a workflow: a sequence of nodes like login, navigate, action, assertion, wait, and setup that models a real user journey. The goal is to capture intent, not keystrokes, so the run is readable and failures are actionable.

Principles

  • Every test should prepare its own data.
  • Tests are a semantic layer: give context and intent, not UI trivia.
  • Actions should be meaningful (e.g. “Create a ticket”), not per-click.
  • Don’t overstuff actions; big blobs make failures hard to pinpoint.

1) Make each test self-sufficient

Tests should not depend on what another test created or on long-lived shared state. If a workflow needs data, create it inside the test:

  • Use a setup node to reference a published flow when shared data build-up is required for multiple workflows.
  • Otherwise, add setup actions at the start of the workflow itself.
  • Prefer unique identifiers (timestamps, short random suffixes) so reruns don’t collide.

This keeps runs deterministic and prevents one failure from cascading into the next.

2) Write steps as human intent

A workflow should read like the steps you would explain to a teammate:

  • “Create a ticket assigned to Support.”
  • “Submit the ticket and confirm it appears in the list.”
  • “Change the ticket status to Closed.”

Use action descriptions and custom instructions to capture the “why” and the “what.” Then add assertions that prove the user-visible result.

3) Choose the right granularity

Good actions are user-meaningful, but still tight enough to diagnose failures.

Too granular

  • “Click New”
  • “Type title”
  • “Type description”
  • “Click Save”

Too stuffed

  • “Create a ticket, assign it, add a comment, upload a file, and verify it appears in three views”

Good

  • “Create a ticket with required fields”
  • “Assign the ticket to Support”
  • “Verify the ticket appears in the queue”

Rule of thumb: if an action crosses multiple screens or changes multiple entities, split it. If it’s a single user goal on a single screen, keep it as one action.

4) Keep actions readable and diagnosable

Overstuffed actions hide where failures happen. Aim for steps that can clearly answer:

  • What was the user trying to do?
  • Where in the UI was it done?
  • What should the user see afterward?

The Flow Designer nodes map directly to how your test reads. When in doubt, favor clarity over compactness.

Example flow outline

  1. Login as Support admin
  2. Navigate to Tickets
  3. Create a ticket with required fields
  4. Assert ticket appears in the list
  5. Assign the ticket to Support
  6. Assert ticket status changes to “Assigned”

Next steps