Test Settings

Every test carries its own configuration — URL, platforms, authentication, timing — managed in the Test Settings dialog (Test → Settings in the visual editor). This page walks through every setting, tab by tab. For reusable values your tests fill into forms, see Variables.

General

Test Settings dialog showing the General tab with URL, name and description fieldsTest Settings dialog showing the General tab with URL, name and description fields
Test Settings — General tab.
  • Test URL (required) — where the browser starts. Set when you create the test and locked afterwards; if the test belongs to a suite with a default URL, the domain is fixed to the suite's and you edit only the path.
  • Test Name — shown in lists, reports, and notifications.
  • Description — what the test covers and why. AI Descriptions can write this for you.
  • Test Suite (when creating) — optionally create the test inside a suite; the suite's default URL and basic auth credentials are inherited.

Test Suites

Lists every suite in your team with a toggle per suite — flip them to add or remove this test from suites without leaving the dialog. Changes apply immediately. See Test Suites.

Platforms

Test Settings Platforms tab showing the Chrome and Firefox desktop/mobile matrixTest Settings Platforms tab showing the Chrome and Firefox desktop/mobile matrix
Test Settings — Platforms tab. Each enabled cell is one run.

Pick which device runs each browser:

  • Chrome — Chromium engine; also representative of Edge, Brave, Opera, and Arc. Desktop and Mobile cells.
  • Firefox — supplemental coverage with best-effort parity with Chrome. Desktop and Mobile cells.

Each enabled cell counts as one run per execution — the tab shows the total ("Runs per execution"), and the sidebar badge shows "N runs". All four cells enabled means every execution consumes 4 runs from your quota.

Firefox mobile and gestures

If you enable Firefox Mobile and your test contains Swipe, Long Press, or Pull to Refresh steps, the dialog warns you: those gestures need Chromium's touch dispatch and will be marked Skipped on Firefox mobile runs. See Actions: Interactions.

Authentication

For sites behind HTTP basic auth (commonly staging environments):

  • Enable Basic Authentication — toggle on, then enter the username and password. Credentials are encrypted at rest.
  • When creating a test inside a suite that already has basic auth configured, the suite's credentials are applied automatically.

This is HTTP-level auth only — for testing your application's own login form, see Testing Login Flows.

Trello

This tab appears only when your team has the Trello integration connected. Toggle Use custom Trello board for this test to override your team's default Trello board for just this test, then pick:

  • Board — the Trello board for this test's cards.
  • Failure List — cards are created here when the test fails.
  • Resolved List — cards are moved here when the test passes again.

Advanced

Test Settings Advanced tab with timeout, step delay and verification togglesTest Settings Advanced tab with timeout, step delay and verification toggles
Test Settings — Advanced tab.
  • Test Timeout — maximum time for the whole run, 30–1200 seconds (default 300). Runs exceeding it are stopped and reported as failed.
  • Step Delay — wait between steps, 100–5000 ms (default 500). Raise it for slow or animation-heavy sites instead of sprinkling Wait steps; lower it to speed up runs on snappy pages.
  • Auto-dismiss cookie banners (default on) — automatically accepts or removes consent overlays on the tested page. It recognizes most common consent banners, but fully custom ones may need an explicit Click step instead. Turn it off if your test verifies the consent banner itself.
  • Skip DOM verification (default off) — DontBreak finds elements visually. When the pixel-perfect (template) match fails and the runner falls back to feature-based (SIFT) matching, it cross-checks the resolved element's id/data-testid attributes against what was recorded — that cross-check is DOM verification, a safety gate against clicking the wrong element. If your site generates dynamic identifiers on every load (common with some frameworks), the gate can over-reject correct matches; enable this setting to skip it. Pixel-perfect matches always bypass the gate regardless. See Test Reliability.
  • Variables — reusable values and built-in dynamic data your tests fill into forms
  • Test Suites — shared URL, auth, and grouping across tests
  • Browsers & Devices — the platform matrix in detail