Skip to main content
Spur’s PR Agent runs functional tests on your deployed app to check the behavior changed by a pull request (PR). After setup, comment:
A bare @spur is enough when the PR and saved instructions already provide the context. You do not need to select tests, write test steps, or add a testing prompt for each PR.
Spur reads the code change, the PR description, linked tickets, and your saved settings to decide what to test. It runs the checks in a real browser and posts the results on the PR. Add guidance only when you want to steer a particular check. If you turn on automatic testing, Spur starts on its own when a PR opens or gets a selected label.

How it works

Spur opens your deployment and follows the user flows that the change affects. For example, after a checkout change, Spur can check that a shopper can still complete a purchase and that discounts still work. Spur runs the saved tests that cover the change. Where coverage is missing, it creates and runs new tests. When the change makes a saved test out of date, it suggests an edit. For new tests, Spur builds the steps against the running app and checks the page as it goes. Before it reports a pass, it reviews the recorded steps and screenshots against the intended behavior. You get browser evidence to use with your code review. You can start without saved tests. When you save useful generated tests, Spur can run them on later PRs.

Fit testing into your PR workflow

1

Set up once

Connect the repository and select its deployment and Spur environment. Add test accounts or shared instructions if your app needs them. Choose whether testing starts automatically or when someone comments @spur.Follow Set Up the PR Agent.
2

Let Spur check the change

Open your PR and let your run policy start testing, or post @spur in a new PR conversation comment. Spur uses the saved environment and deployment without asking you to set them again.Keep the mention outside quotes and code blocks. Commenters need write, maintain, or admin repository access.
3

Review the evidence

Read the report on the PR, then open a result for the screenshots, recording, and steps. You decide whether to merge and which tests to keep.

Reviewing a test run

The PR comment shows what Spur tested, the deployment it used, and the results. Open a result in Spur for the detailed evidence. A failed test needs investigation. An error means the check could not finish. Spur does not block merges or change your code. See Review and Save PR Agent Tests for the report and result states.

Add guidance when you need it

To steer one request, say what you want in the comment. Spur still starts from the PR and your saved setup.
Describe the outcome you want checked. Spur chooses the browser steps. See recommended practices for useful context.
Replace the URL and environment name with your own. For a shared QA site, deploy the change before you request tests. Each request tests one deployment. See environment and deployment setup.
If Spur needs more information, its reply names the missing detail. Add that detail in a new @spur comment. See setup troubleshooting for preview or login problems.

Keeping a generated test

Spur does not add generated tests to your Test Library automatically. Use Save generated tests to keep the ones you want in a Test Suite. You also decide which suggested edits to apply to existing tests. See Save generated tests.

Saving testing instructions

Save recurring facts about your app once under Testing instructions: terminology, roles, login guidance, and test data. Spur uses them on every later PR. A comment can add instructions for one request without changing what you saved. See Testing instructions and glossary.

Setup

Connect the repository and choose when testing starts.

Results

Inspect the report and save useful tests.