TestSprite 3.0 - Let a fleet of parallel agents test your app in minutes
by•
TestSprite generates and runs end-to-end tests for your app, autonomously.
For backend, we can now generate complex integration tests with dynamic variables, auto-cleanup, and Data Flow debugging.
For frontend, we now send a fleet of parallel AI agents to explore your app first — clicking through every feature like real users, then feeding results into testing. We're the first to do this.
3.0 also adds auto-heal for UI drift, auto-auth for regression, and a CLI for Claude Code, Codex users.
Replies
TestSprite
Hey Product Hunt 👋
I'm Yunhao, co-founder and CEO of @TestSprite.
Today we're shipping TestSprite 3.0 — autonomous end-to-end testing that actually understands what your app does, not just what your code says.
✍️ Here's how it works:
Point TestSprite at your live web app or API endpoints. Drop in your PRD or product spec if you have one (strongly recommended — it sharpens what we test).
We send a swarm of AI agents to explore it in parallel — clicking through every feature like real users.
They generate full backend + frontend test suites from what they saw. Then run, debug, and auto-heal them for you.
🚀 What's new in 3.0:
Parallel exploration fleet — dozens of agents map your app before a single test is written. As far as we can tell, no one else is doing this yet.
Backend gets serious — multi-dependency integration tests, Dynamic Variables, Auto Cleanup, and a Data Flow view that makes debugging an agent-generated test feel like debugging your own code.
Frontend tests auto-heal when your UI drifts. Auto-auth keeps nightly regression sane.
Accuracy up ~40% — and it really shows on complex enterprise projects, where most agents fall apart.
Coverage jumped from ~20 to 50+ meaningful cases per run.
CLI for Claude Code and Codex users — coming soon, right inside your terminal.
🎉 Launch day offer: Sign up for our Starter package today and get your first month free.
Come tell us what you'd want TestSprite to break on. We're reading every comment today 🚀
TestSprite
Really impressive release 🚀
@TestSprite @jiao_yunhao Hey Yunhao, congrats on shipping 3.0
The parallel exploration fleet is the part I want to poke at. If dozens of agents are clicking through a live app like real users before any test is written, they are also triggering real side effects: form submits, outbound emails, writes to the DB, burned API rate limits. How does TestSprite contain that? Sandboxed env required, automatic detection of destructive actions, or some dry-run mode for the exploration pass? Asking because "explore like real users" and "do not actually charge the card or email the customer" are in direct tension, and that tension is where exploration agents usually get scary.
zero.xyz
@TestSprite @jiao_yunhao This is a really sick QA agent system. Seems like it goes way beyond Qodo / CodeRabbit. Excited to tell my engineering team!
TestSprite
Every piece of community feedback has shaped what we have built, and we are deeply grateful for that!
The goal has always stayed the same: learn and build from what users actually need. We hope this latest version shows how much we truly care. ❤️
TestSprite
@adam_ji1 Really appreciate how much the team listens to user feedback. You can genuinely feel that a lot of the 3.0 improvements came from real developer pain points 👏
Interesting! Auto-heal for UI drift sounds great in demos and gets dangerous in CI. How do you separate the two without a human in the loop? Congrats on the launch
TestSprite
@artstavenka1 Thanks Art! Really fair concern — we thought about this a lot. Auto-heal isn't on by default; it's an opt-in toggle per run. So the typical setup is: off in CI (so it fails loud like you'd want), on locally or in staging where the dev reviews the proposed fix as a diff before it gets merged. That way healing never silently rewrites assertions on main. Happy to share more if you want to dig in — and thanks for the kind words on the launch! 🙏
HeyForm
Super cool launch 🚀
Love seeing testing evolve alongside AI coding tools. The autonomous workflow + CLI support for Claude Code/Codex users feels especially timely.
TestSprite
@itsluo Thanks so much! We’ve been thinking a lot about how testing needs to evolve alongside AI coding workflows. The CLI support for Claude Code and Codex users is a big step toward making TestSprite feel more native inside AI-first development environments 🚀
The autonomous debugging part sounds wild 🤯 How many retries does the system usually need before stabilizing a test?
TestSprite
@ana_popescu2 It depends on the complexity of the workflow 😄
A big focus for us in 3.0 was reducing unnecessary retry loops and making the debugging path much more traceable.
TestSprite
Appreciate everyone checking out the launch today ❤️
This release took a lot of iteration, especially around autonomous frontend exploration and regression reliability. We wanted TestSprite 3.0 to go beyond simply generating test scripts, and actually understand how users move through an app before creating tests.
Excited to hear your feedback and keep improving it from here!
AgentQL
Congrats on the release! Looks great!
TestSprite
@pasha_dudka Thanks Pasha!
The backend integration testing upgrades sound powerful, especially Dynamic Variables and Auto Cleanup. Can TestSprite also manage dependent API chains with temporary tokens and session-based workflows?
TestSprite
@andrew_paul11 Yes — that’s actually one of the scenarios we designed the backend workflow for. Dynamic Variables + Data Flow tracking allow TestSprite to handle dependent API chains, including temporary tokens, session-based auth flows, and multi-step request dependencies. The goal is to make complex integration testing feel much closer to debugging real application logic rather than isolated API calls.
Congrats on the launch!
The parallel exploration fleet really caught my attention because most testing tools still operate sequentially. How do you coordinate multiple agents without them duplicating the same testing paths repeatedly?
@imogen_wallace Thanks! Naive parallel actually makes things worse — N agents all racing to click "Sign Up" first isn't faster, just noisier. Our approach is to make them orthogonal by construction: a discovery pass first breaks the app into distinct features, then we fan out one agent per feature. So they're not competing on the same paths — they're each owning a different slice.
Generating 50+ meaningful cases automatically is a massive jump compared to traditional approaches. How do you internally define “meaningful” coverage versus repetitive or low-value test cases?
TestSprite
@antonio_manuel1 Great question. For us, “meaningful” coverage is less about raw test count and more about validating critical workflows, state changes, user paths, and failure-prone logic instead of generating repetitive variations.