Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.spurtest.com/llms.txt

Use this file to discover all available pages before exploring further.

​
Overview

The Spur GitHub App analyzes every pull request the moment it’s opened. It looks at the files changed and the actual code diff, then automatically generates a focused set of browser tests that cover the change. Spur also scans your existing test suite and triggers any relevant saved tests, so every PR gets both fresh, change-aware tests and proven regression coverage.

Auto-generated tests

Spur reads the diff and generates tests targeting exactly what changed — uppercase handling, edge cases, new flows, etc.

Relevant existing tests

Spur scans your saved tests and runs the ones related to the changed area of your app.

Preview-aware

Spur picks up the preview deployment URL from your PR (e.g. Vercel) and runs tests against that build.

Re-trigger with context

@-mention Spur in a PR comment to re-run with extra context like “log in as an admin user.”
Looking for the YAML-based CI/CD setup instead? See the GitHub CI/CD integration — that flow runs your existing test plans on every PR via GitHub Actions. The GitHub Agent described here is a separate, AI-driven flow that generates tests on the fly.

​
How it works

1

Open a pull request

As soon as you open a PR, the Spur GitHub App reads the changed files, the diff, and the PR title and description to understand the change.
PR diff being analyzed by Spur
2

Spur comments on the PR

A comment from the Spur app appears on your PR with the set of tests it generated for the change. Each test targets a specific case Spur thinks is worth verifying — for a search-input change, that might be uppercase matching, accented characters, internal whitespace, and case-insensitive matching.
Spur PR comment with generated tests
3

Existing tests are triggered too

Spur also searches your saved tests for ones that touch the same area of the app and kicks those off as part of the same PR run. In the comment, generated tests and existing tests are listed separately so you can tell them apart.
Existing relevant test triggered on the PR
4

Tests run on the preview deployment

Spur automatically detects the preview URL from the PR (for example a Vercel preview) and runs every test against that deployment. No environment configuration is required for the per-PR run.

​
Reviewing a test run

Click any test in the Spur PR comment to open the full run on Spur. You get everything a normal Spur test run gives you:
  • The full list of steps the agent executed
  • Screenshots at each step
  • The deployment URL the test ran against
  • Pass/fail status and failure reasons
If a test fails, this is the place to dig in — step through the screenshots, read the agent’s step descriptions, and figure out whether the failure is a real regression or a flaky expectation in the generated test.
Spur test run detail page

​
Keeping a generated test

By default, generated tests are discarded after the PR run — they’re scoped to that PR and don’t pollute your suite. If a generated test is good enough that you want it to keep running on future PRs and as part of your test plans, save it:
1

Click Keep Test

On the test result, click Keep Test.
Keep Test button
2

Add it to a suite

You’ll be prompted to add the test to an existing suite or create a new one. Once saved, the test behaves like any other Spur test and will be re-triggered on future PRs that touch the same area of the code.
For tests that came from your existing suite, the test result is identical to a normal Spur run — no extra step needed.

​
Re-triggering with extra context

You can ask Spur to re-analyze a PR and apply new context by @-mentioning the app in a PR comment. 
@spur re-trigger the tests, but let's log in as an admin user instead.
When you submit the comment, Spur:
  1. Reacts to the comment to confirm it picked up the mention.
  2. Re-reads the PR diff and preview URL.
  3. Generates a fresh set of tests, applying your extra context (in the example above, logging in as admin instead of a normal user).
  4. Posts the new run back to the PR.
This is useful for nudging the agent toward specific user roles, prerequisite states, or operational quirks of your app that aren’t obvious from the diff alone.
@-mention re-trigger

​
Setting default context

If you find yourself repeating the same context on every PR (“log in as admin,” “the staging env requires this header,” etc.), set it once as default context on the integration.
1

Open the GitHub integration

In Spur, go to Integrations and open GitHub.
2

Add default context

Find the Default context section. Enter any prerequisites or operational notes you want Spur to apply on every PR run — for example, admin credentials, normal user credentials, required feature flags, or UI quirks the agent should be aware of.
Default context settings
3

Save changes

Click Save Changes. From now on, every PR analysis Spur runs will include this context alongside the PR diff, weighted into how it generates and selects tests.
Default context is global — it’s applied to every PR. Use a PR-comment @-mention when you only want extra context for a single run.

​
FAQ

No. Generated tests are discarded by default after the PR closes. Click Keep Test on any generated test to promote it into one of your suites.
Spur scans your saved tests and matches them against the area of the app that changed in the PR. Only tests Spur considers relevant to the diff are triggered — your full suite is not run on every PR.
Spur extracts the preview deployment URL from the PR automatically. Vercel preview deploys are supported out of the box; other providers that post a preview URL in PR comments also work.
Yes. Push new commits and @-mention Spur in a PR comment asking it to re-trigger. Spur will re-analyze the latest diff and preview URL.