Common Pitfalls When Writing Tests in Spur
Avoid these common authoring mistakes to ensure your tests run reliably and clearly communicate intent.
1. Incorrect or Misformatted Starting URL
1. Incorrect or Misformatted Starting URL
What happens:
Tests fail immediately or start on the wrong page.
Why it matters:
The Start URL is where Spur begins your test flow—it must be complete and properly formatted.
Correct example:
Incorrect examples:
Always copy and paste the URL directly from the browser’s address bar.
2. Mixing Actions Inside “Verify” Steps
2. Mixing Actions Inside “Verify” Steps
What happens:
Tests become semantically unclear or are misinterpreted.
Bad example:
Good example:
Rule of thumb:
- Actions = things the test does (e.g., click, scroll)
- Verifications = things the test checks (e.g., visible, present)
Keep them in separate steps.
3. Non-Scenario Table Tests in Scenario Table Test Suite
3. Non-Scenario Table Tests in Scenario Table Test Suite
What happens:
Static tests placed inside a scenario table suite will execute once per scenario row, potentially causing duplicate confirmations or side effects.
Bad example:
Good practice:
Keep tests that do not rely on scenario table variables in a separate test or suite. This prevents static verifications from running multiple times.
4. Using “Go to URL” Inside Test Steps
4. Using “Go to URL” Inside Test Steps
What happens:
Spur can’t interpret Go to URL commands mid-test, causing scripts to fail.
Bad example:
Good example:
-
Set the Start URL in your test’s settings:
-
Use actions for in-test navigation:
5. Tab/Browser Navigations
5. Tab/Browser Navigations
6. Scrolling
6. Scrolling
What happens:
The agent only interacts with elements in view unless instructed otherwise. Tests may fail to locate off-screen elements.
What to do:
Explicitly include scroll steps before verifications or actions. For example:
The agent will also scroll to find out-of-viewport items, but specifying scrolls improves test stability. See Discrete Actions: Scroll.
Remember that the agent sees only what a human sees. Include scroll instructions to ensure consistent element visibility.
7. Accessing Restricted Domains via Preview Editor
7. Accessing Restricted Domains via Preview Editor
What happens:
Direct navigation to restricted domains (e.g., spurmail.com) may be blocked due to IP restrictions.
What to do:
Access these domains through the Preview Editor, which proxies requests and bypasses IP blocks. When you run the test normally, the agent routes via Preview Editor and executes steps successfully.
Use the Preview Editor view to interact with spurmail.com. Direct browser access may show a blocked IP error, but tests will pass when executed through Spur Preview.
✅ Authoring Do’s & Don’ts
| ❌ Don’t | ✅ Do |
|---|---|
| Use incomplete or incorrect URLs | Use full URLs including https://, copy directly |
| Mix actions and verifications | Keep actions and checks in separate steps |
| Use “Go to URL” mid-test | Set the start URL in test settings |
| Combine static steps inside scenario loops | Keep tables fully dynamic; extract shared setup |
| Attempt tab or browser navigations without browser actions | Use browser action steps for tab/window navigation |
| Omit scroll instructions | Explicitly include scroll steps before actions/verifications |
| Rely on direct navigation to restricted domains (e.g., spurmail.com) | Access via Preview Editor to bypass IP restrictions |