Creating tests
Using the test builder
Open Tests > Tests and create a new test from the sidebar. Tests save automatically as you edit.
Each direct step has three main fields:
Instruction - the action or outcome you want the agent to complete.
Details - extra context, success criteria, viewport, or anything the agent should pay attention to.
On failure - whether the run should stop immediately or continue to the next step.
You can reorder steps, duplicate them, and keep the builder as granular as you need.
Example steps
These examples show the level of detail that usually works well. The goal is to tell the agent what to do and what success looks like without tying the step to fragile wording or layout details.
Example: log in
Instruction: Log in as the Admin user.
Details: Use the saved Admin user test account. If you start on the homepage, click Sign in first. The step is complete once the dashboard loads.
Example: navigate to a feature
Instruction: Open the Billing page from Settings.
Details: Go to Settings, then Billing. The step is complete when the current plan card or subscription details are visible.
Example: create something
Instruction: Create a new project called Docs smoke test.
Details: Click New project, enter the name, submit the form, and confirm the new project appears in the project list.
Example: verify behavior
Instruction: Invite a teammate and confirm the invitation was sent.
Details: Open the team members screen, invite [email protected], and check that the invited user appears with a pending status.
A vague instruction like Test onboarding leaves too much to interpretation. A clearer version would break that into smaller steps such as Click Start onboarding, Complete the profile form, and Confirm the welcome screen appears.
Continue behavior
Every step has an On failure setting:
Stop on failure - if the agent marks the step as a warning or error, the run stops and the remaining steps are cancelled.
Continue on failure - the warning or error is still recorded, but Buildprint continues with the next step.
Continuing does not ignore the problem. A run can still finish with a warning or error status even if later steps continue.
Components
If part of your flow is reused across multiple tests, turn it into a Reusable component. Components are useful for repeated actions like logging in, opening a settings page, or navigating to the same part of the app before the real assertions begin.
Components are created in the same builder as tests. Once a definition is marked as reusable, you can insert it into other tests as a component step. Components are not run directly, and they cannot be added to groups.
When a test run starts, Buildprint expands component steps into normal runnable steps behind the scenes, then groups them together again in the results so the run stays easy to read.
Test groups
Groups let you organize and run several tests together. Create a group from the sidebar, then add or remove tests from it. Groups only contain tests, not components.
This is useful when you want one-click regression coverage for a feature area such as auth, onboarding, billing, or admin flows.
Adding files
In each test, you can optionally add files. These are accessible to the agent running the test, and are useful for providing files that it should upload or otherwise use in its testing.