New · v2 TestingForge v2 is live — twice the functionality at the same subscription price. See what's new →
v2 2× features
Truth sheet

What TestingForge does (and what it doesn't)

A truth sheet, not a marketing page. What we actually generate from your repo, what we never touch, where AI is in the loop, and the limits we ship today.

Apr 22, 2026 5 min read TestingForge Team

Why this page exists

Most "AI testing" pages on the internet promise everything. This one is the opposite. We are writing down what TestingForge actually does today, what it explicitly does not do, and where the limits sit. If you are evaluating us for a real product, this page is more useful than the homepage.

What we do

  • We connect to your repository and your OpenAPI / spec, then generate a structured API test suite — request shapes, expected responses, error cases, auth flows.
  • We run that suite in CI on every push or pull request and report failures back where the code change happened.
  • When your API changes, we propose suite updates as diffs. A human reviewer (you, or our QA engineer) approves them. Nothing lands silently.
  • We keep the suite organized as your codebase grows — by service, by resource, by feature flag — so it stays usable instead of becoming a 4 000-test graveyard.

What we do not do

  • We do not generate browser / UI end-to-end tests. No Playwright recorder, no "click everything and pray".
  • We do not chase pixels, selectors, or visual diffs. That is a different problem with different trade-offs.
  • We do not auto-merge anything. Every AI proposal goes through a review step.
  • We do not pretend the model is always right. When the AI is unsure, we say so, and the human decides.

Where AI is in the loop (and where it is not)

AI helps us read the codebase, draft tests, and detect drift between the API and the suite. It is good at boilerplate and at noticing "this endpoint changed shape, the tests still assume the old shape". It is not good at deciding business rules, security boundaries, or what "correct" means for your domain. Those decisions stay with humans.

Stacks we currently support well

HTTP/REST APIs and OpenAPI-described services are the sweet spot. GraphQL works but is younger in our pipeline. gRPC and event-driven systems are on the roadmap and not the place to evaluate us today. If you are unsure, talk to us — we will tell you straight whether you are on the happy path.

Limits we ship today

  • We need access to the repo. Closed-source-only environments are harder.
  • We assume you can run the API in CI (containers, ephemeral DB, fixtures). If your test environment does not exist yet, we can help, but it is week-1 work, not magic.
  • Coverage on day one will not be 100 %. It will be useful — usually enough to catch contract drift and the obvious regressions — and grow from there.

Who this fits

Product teams that ship APIs every week, do not want to babysit a Postman collection, and do not have the headcount to keep an in-house QA team writing API tests forever. If that sounds like you, the rest of the website is worth reading. If you are looking for browser E2E or visual regression — we are honestly not the right tool, and we would rather tell you now than three weeks into onboarding.