TestSprite Hackathon Season 4 had a simple theme: One Week. One Loop. Every PR. Wire TestSprite into your repo so every pull request gets tested on its own, let your coding agent fix what fails, and let the check rerun by itself.
I built AgentPulse, a mission-control dashboard for teams that ship with AI coding agents: fleet reliability telemetry, a pipeline DAG studio, a test-scenario repository, a chaos and webhook simulator, and an inspector for the write → test → fix → test-again loop.
#
The setup
A suite generated from the live app. In the TestSprite 3.0 web portal, the projectagentpulse-pi crawled the deployed site and produced 33 end-to-end tests across five use cases: Fleet Overview, Pipeline Studio, Test Scenarios, the Self-Healing Verification Loop, and Chaos Testing & Webhook Simulation. I later added four input-validation cases, for 37 in total.
2.
A preview for every PR. The Vercel project is connected to GitHub, so each pull request gets its own preview deployment.
3.
A TestSprite trigger on that preview. In the portal's GitHub Action tab, the trigger fires on thePreview deployment event and targetshttps://agentpulse-git-{branch-slug}-<team>.vercel.app , so the suite runs against the PR's own code, not production.
4.
A merge gate. TestSprite reports aTestSprite V3 status, and branch protection onmain requires it, admins included. A red check really does block the merge.
#
Gotchas worth knowing
Vercel Deployment Protection. On Hobby, previews sit behind Vercel login by default, so TestSprite would happily "test" the login page. My app is a public demo with no auth, so I turned protection off for previews. Don't reach for a bypass secret in the target URL: TestSprite prints that URL in a public PR comment. #
63-character hostnames. Vercel truncates long preview subdomains, which breaks a{branch-slug} pattern. Short branch names (mine wasverify-gate ) keep the URL predictable. #
A trigger only sees new events. I created the trigger after the PR's first preview, so I redeployed that preview to fire the first run. #
Keep your checks honest. An earlier CI job in this repo was named "TestSprite 3.0 Verification Gate" but only rannpm test plus an archived action with no credentials. I renamed it toBuild & Unit Tests and let the real TestSprite App check carry its own name.
#
The loop on PR #5
The PR started as docs plus four new validation cases for the "new test scenario" form. Here is what TestSprite did with it:
33/37, merge blocked. The four new cases failed against the preview. The form accepted an expected HTTP status of0 ,999 or blank (storing200 while the assertion kept the raw value), and it rejected a target path with surrounding spaces because it checked the leading slash before trimming. Each failure came with screenshots and a suggested fix prompt for the coding agent.
2.
Fix 1 → 35/37. My coding agent (Claude Code) moved validation into a small framework-free module with unit tests: status must be a whole number from 100 to 599, and title and path are trimmed first. TestSprite reran on its own. The0 ,999 and trimming cases passed, but two cases were still red. The blank one turned out to be a subtler bug. The test cleared the field with a scripted fill, which changes the DOM without firing React'sonChange , so the submit handler validated a stale"200" from state. Autofill can do the same thing to real users.
3.
Fix 2 → 36/37. The form now reads its values withFormData on submit, so it validates what is actually in the fields. That left the other red case: Fleet Overview showed monitored pipelines but gave no way to open a specific one. "View Pipelines" always opened the first pipeline.
4.
Fix 3 → 37/37. Each pipeline card got a "View Details" button that opens that pipeline in Pipeline Studio. The check went green and the merge gate opened.
#
What I took away
End-to-end tests on a real preview catch what unit tests can't. The stale-state bug lived between the DOM and React state. My unit tests passed the whole time. #
The merge gate is what makes it a loop. Without branch protection, a red TestSprite comment is just advice. With it, the PR can't move until the suite is green. #
The failure reports are agent-ready. Every failing case came with what was observed and a fix prompt, which is exactly the input a coding agent needs for the next commit.
Thanks to the TestSprite team for running Season 4. If you're wiring TestSprite into your own repo, start with the preview trigger and the merge gate, and keep your branch names short.