Your AI-Built App Has Zero Tests. Here's How to Fix That in One Command.

The Vibe Coding Maintenance Trap

You build an app with Cursor or Claude Code, it ships, users sign up, and for a moment it feels like the promise is real. Then the second phase starts: you change one thing, another thing breaks, you ask the AI to fix that, and suddenly you are three layers deep in a whack-a-mole maintenance loop.

The problem is not that AI always writes unusable code. The problem is that it usually ships code without a serious safety net. No test strategy, no prioritization, no audit trail, and nothing that tells you what is safe to refactor without collateral damage.

That is why so many AI-built apps feel fast to create and expensive to maintain. When a repo has zero tests, every change becomes a coin flip. You are not shipping with confidence. You are shipping with luck.

it('renders without crashing', () => {
  render(<PostsPage />)
})

// It passes.
// It catches nothing.
// Your app can still be on fire.

Introducing TestGen

TestGen is a Claude Code and Codex-oriented testing skill that scans your codebase, identifies what is worth testing first, generates real tests, runs them, and writes findings reports that tell you what actually broke.

That distinction matters. This is not 'write some tests' as a vague prompt. It is a structured workflow: scan, audit, generate, execute, diagnose. The output is not only test files. It is also an explicit explanation of what was tested, what failed, and whether the likely problem is product logic or infrastructure.

If you want the full breakdown before checkout, the fastest internal route is the product page at https://0toprod.dev/products/testgen. If you already know you want the pack, the direct checkout is https://marinedep.gumroad.com/l/testgen. If you want to validate the workflow first, the free entry point is https://github.com/Marinou92/testgen.

Phase 1 — Scan What Is Actually in the Repo

The first layer is a deterministic scanner. It runs instantly, burns zero tokens, and maps what is testable before the agent starts generating anything. That means framework detection, auth detection, runner detection, and a first-pass view of where the high-risk logic probably lives.

This is also where the free version already gives real value. If your repo has no test runner, the free GitHub version is enough to detect that, set up the smallest viable stack, and stop you from losing time on manual harness work.

TestGen Scan — your-project/

Framework:     Next.js 15 (App Router)
Test runner:   none detected -> will setup Vitest
Auth:          Supabase (@supabase/ssr)
Database:      Supabase (PostgreSQL)

Testable targets:

TYPE                   COUNT   PRIORITY
Server Actions         4       high
API Route Handlers     3       high
Utility functions      8       medium
React components       12      medium
Middleware             1       high

Phase 2 — Audit the Code That Can Actually Hurt You

Most teams skip prioritization entirely. They generate shallow tests on random files, inflate the test count, and still leave the dangerous paths uncovered. TestGen fixes that by writing a real TEST-AUDIT.md before the heavy generation pass starts.

The audit step ranks the top five targets, maps system boundaries, and tells the generator where the real risk lives. In practice that means Server Actions, route handlers, auth-sensitive flows, mutations, and the component logic that actually changes state.

• Server Actions with auth, validation, and cache invalidation.
• API routes with wrong-method, bad-input, and failure-path coverage.
• Validators, hooks, and utility logic before visual-only UI coverage.
• Boundary mapping for App Router, Supabase, NextAuth, Prisma, Stripe, React Query, and Zustand.

Phase 3 — Generate Real Tests, Not Decorative Ones

When people say AI test generation is weak, they usually mean they asked for tests and got decorative coverage: renders without crashing, happy-path assertions, or snapshots nobody trusts. TestGen is designed specifically to avoid that.

The generation layer covers five useful buckets: server actions, API route handlers, utilities and validators, behavior-heavy components, and optional E2E flows when browser coverage is justified. That is how you move from test quantity to test value.

describe('createPost', () => {
  it('works', async () => {
    const result = await createPost(state, formData)
    expect(result).toBeTruthy()
  })
})

// One test.
// No auth.
// No validation.
// No failure path.

describe('createPost', () => {
  it('rejects unauthed users', async () => {
    mockNoSession()
    const result = await createPost(state, formData)
    expect(result.error).toBe('Unauthed')
    expect(insertSpy).not.toHaveBeenCalled()
  })

  it('validates with Zod', async () => {})
  it('creates + revalidates', async () => {})
  it('handles database failure', async () => {})
})

Stack-Specific Adapters Are the Difference Between Useful and Generic

Generic test generation fails because the hardest part of testing modern apps is rarely the assertion itself. The real cost is wiring the boundaries correctly: cookies, headers, redirects, auth, database clients, billing SDKs, state stores, and framework helpers.

That is why TestGen ships reusable adapters instead of pretending every repo looks the same. The current pack covers App Router boundaries, Supabase, NextAuth, Prisma, Stripe, React Query, and Zustand so the generated tests can start from patterns that already match the stack.

• next/navigation, next/cache, next/headers, and route-level App Router boundaries.
• Supabase auth and query mocks with getUser()-aligned server behavior.
• NextAuth session handling and server-side auth wrappers.
• Prisma and Stripe wrappers for data and billing paths.
• React Query and Zustand patterns for client-state-heavy apps.

Phase 4 — Run the Suite and Write Findings

The strongest part of the flow is that TestGen does not stop at file generation. It runs the suite and writes TEST_FINDINGS.md. That report is where failing tests become useful, because the point is not just that something failed. The point is why it probably failed.

A raw Vitest failure tells you a test broke. A findings report tells you whether the likely issue is product logic, an infra gap, a mock issue, or a low-value target you should defer.

# Test Findings

## Summary

- tests added: 12
- files changed: source, tests, and Next.js project metadata
- passing: 12
- failing: 0 in final state
- coverage before: not configured
- coverage after: 71.87% statements and lines

## Probable Product Bugs

| Severity | File Or Flow | Failing Test | Observed Behavior | Expected Behavior | Recommended Action |
| --- | --- | --- | --- | --- | --- |
| medium | src/app/actions/create-post.ts | createPost > creates the post and revalidates | deliberate regression changed revalidatePath from /posts to /dashboard | revalidate the posts listing after a successful create | fixed during validation and confirmed with a green rerun |

Free GitHub Version vs Full TestGen

The free repo is the right entry point if you want to validate the approach, scan the project, and repair the testing foundation. The full product is what you buy when you want the repo audit, generation layer, execution pass, adapters, and findings output.

Install in 2 Minutes

The workflow is intentionally local and fast. No SaaS queue, no code upload, no extra account layer between you and the repo.

cp -r full-testgen/ ~/.claude/skills/testgen/

cp -r full-testgen/ ~/.codex/skills/testgen/

Part of the 0toprod Pipeline

TestGen is not meant to live alone. Inside 0toprod, it sits downstream from the rules and security layers. The AI Rules Pack prevents recurring architectural mistakes upstream. ShipSafe catches production and security gaps. TestGen verifies the code path with executable tests.

That makes the pipeline feel coherent instead of fragmented: prevention, detection, verification.

FAQ

Stop Shipping Blind

If your AI-built app still has zero tests, the goal is not to feel worse about that. The goal is to fix it without spending the next week hand-rolling a brittle harness from scratch.