Suites and selection

Give each group of workflows a name with describe. Keep its setup and cleanup there too:

import { describe, test, beforeEach } from 'dyno';

describe('Authentication', () => {
  beforeEach(async ({ app }) => {
    await app.goto('/login');
  });

  test('opens registration', async ({ I }) => {
    await I.click('Create account');
    await I.find('Start testing UI changes').visible();
  });
});

Every test and hook belongs inside a describe. You can nest suites or have several at the top level. Suite definitions are synchronous; put async work in hooks or tests.

Set up and clean up

beforeEach runs from the outer suite inward. afterEach runs from the inner suite outward, including after failure for suites the test entered. Cleanup gets fresh APIs and its own budget, so one failed assertion doesn’t use up the cleanup time.

Each test starts with fresh app and test documents. Cookies, browser storage, service workers and backend records persist. Reset those through your app’s fixtures and hooks; use Node teardown for resources that outlive a test. Configuration covers that setup.

Run just what you’re editing

dyno --suite Authentication
dyno --file login.test.js
dyno --test 'Authentication › opens registration'
dyno --id '<ID from test discovery/results>'

File, suite and ID flags can repeat. Different kinds narrow the selection together. If a short test name is ambiguous, Dyno tells you how to pick one.

Use test.only or describe.only for local focus. CI rejects them by default. test.skip('later') and describe.skip report skipped tests without running their hooks or bodies.

Names must be unique within a suite. Stable IDs use the file, suite path and test name, so adding or reordering other tests doesn’t change them. The reporter uses those IDs for reruns.