> ## Documentation Index > Fetch the complete documentation index at: https://docs.revolte.ai/llms.txt > Use this file to discover all available pages before exploring further. # Generate Tests for Existing Code > Find coverage gaps in an existing feature and generate tests that follow your project's conventions. Writing tests for code you didn't just write means first figuring out what's already covered and what isn't. This walkthrough has Revolte map an existing feature's coverage, propose a test plan, and only then implement tests — so the result targets real gaps instead of duplicating existing coverage. ***
Before writing anything, ask Revolte to map what the feature does and how much of it is already tested — useful when you didn't write the code yourself. Read through the summary it returns; the plan in the next step is only as good as the gaps identified here. ```text theme={"dark"} Analyze the checkout flow and summarize the current test coverage. Focus on: - How orders are created and processed. - The payment validation flow. - Existing unit and integration tests. - Scenarios that aren't covered today. Don't make changes yet — just summarize the flow, the gaps, and what you'd recommend testing. ``` With the gaps identified, have Revolte turn them into a concrete, prioritized plan before any tests get written. Skim the plan and reorder or drop anything that doesn't match what you'd actually prioritize — it's the checklist the next step implements against. ```text theme={"dark"} Based on that analysis, put together a test plan to improve checkout flow coverage. Include: - Missing critical scenarios. - Successful checkout paths. - Payment failure cases. - Invalid input handling. - Edge cases around order creation. Prioritize by which tests give the most confidence. ``` If a priority looks off or a scenario's missing, say so before anything gets implemented — it's a lot cheaper to fix here than after the tests are written. Skip this if the plan already looks right. ```text theme={"dark"} Move invalid input handling above payment failure cases, and add a scenario for partial refunds. ``` Once the plan looks right, approving it is enough — Revolte already has the plan from the session, so there's no need to restate it. ```text theme={"dark"} Looks good, implement it. Follow the existing testing patterns in the repo, run the suite, and fix any failures. ``` While that runs, here's what to expect in the session before you're asked to review anything — Revolte works through it in stages: * **Analyzes the feature** — what it does and what it depends on. * **Reviews existing coverage** — what's tested today and where the real gaps are. * **Plans scenarios** — critical paths, edge cases, and failure modes worth covering. * **Writes the tests** — matching your project's existing structure and conventions. * **Verifies** — runs the suite, fixes failures, and confirms coverage actually improved. If you're in the chat view, click **View changes** to open the diff on the right and follow along. Once the suite lands and you've checked coverage actually improved, stay in the same session and go after the scenarios that matter most for reliability: ```text theme={"dark"} Add regression tests for failed payment and order rollback scenarios. ``` Or point Revolte at the suite itself rather than new coverage: ```text theme={"dark"} Review the current checkout tests and flag anything that's flaky or hard to maintain. ```
*** ## Related * [Investigate and Fix a Production Bug](/use-cases/fix-a-bug) * [Build APIs from a Spec](/use-cases/api-from-spec)