> ## Documentation Index
> Fetch the complete documentation index at: https://docs.blitzy.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Add Testing

> Implement comprehensive test coverage for existing code using AI-Native testing capabilities

Untested code is a liability that grows with every commit. Teams know they need better coverage but writing tests is repetitive work that rarely wins priority against feature delivery. Blitzy closes that gap: it analyzes your code structure, identifies test scenarios including edge cases, and generates tests in your framework (Jest, Pytest, JUnit) that follow your existing patterns and hit your coverage targets.

<Warning>
  Blitzy automatically provides acceptable unit test coverage. You must explicitly specify integration, E2E, and functional test requirements in your prompts with clear scope definition.
</Warning>

<Card title="Ready to add testing?" icon="rocket" href="/templates/code-quality-maintenance/add-testing">
  Use the **Add Testing Template** to get started with a structured prompt
</Card>

<Note>
  **Jump to:** [When to Use](#when-to-use-this-approach) | [Prompt Structure](#prompt-structure) | [Key Considerations](#key-considerations) | [Common Patterns](#common-patterns) | [Troubleshooting](#troubleshooting)
</Note>

## When to Use This Approach

<Tabs>
  <Tab title="Coverage Gap Closure">
    Bring modules up to 80%+ coverage targets with unit tests that cover success paths, error conditions, and boundary values.
  </Tab>

  <Tab title="Integration Validation">
    Verify that components, services, and APIs work correctly together with real dependency interactions.
  </Tab>

  <Tab title="End-to-End Workflows">
    Test critical user journeys from start to finish to catch issues that unit tests miss.
  </Tab>

  <Tab title="Regression Prevention">
    Add tests for every bug fix that fail before the fix and pass after, preventing the same issue from returning.
  </Tab>
</Tabs>

## Prompt Structure

Follow the [Golden Rules](/prompt-engineering/golden-rules) when writing your testing prompt. Focus especially on:

* **Coverage Targets** - Specify percentage goals and which modules require coverage
* **Test Framework** - Define framework (Jest, Pytest, JUnit) and assertion libraries
* **Mocking Strategy** - List external dependencies to mock and integration points to test
* **Test Patterns** - Reference existing test files showing preferred organization and style

## Key Considerations

<CardGroup cols={2}>
  <Card title="Coverage Targets Drive Scope" icon="bullseye">
    Specify exact coverage percentage (e.g., 80%+ line coverage, 90%+ branch coverage) and identify which modules require testing. Vague coverage requests lead to incomplete or excessive test generation.
  </Card>

  <Card title="Mocking Strategy Affects Isolation" icon="clone">
    Define which external dependencies to mock (APIs, databases, services) and which to use in integration tests. Improper mocking creates brittle tests or insufficient validation.
  </Card>

  <Card title="Test Patterns Ensure Consistency" icon="code">
    Reference existing test files showing preferred patterns (describe blocks, assertion style, fixture usage). Inconsistent test patterns make test suites harder to maintain.
  </Card>

  <Card title="E2E Scope Requires Explicit Definition" icon="route">
    Integration and E2E tests need explicit scope definition including user workflows, API contracts, and database states. Without explicit scope, Blitzy generates only unit tests.
  </Card>
</CardGroup>

## Common Patterns

**Unit test addition** - Generate tests for individual functions/methods with success cases, error conditions, edge cases, and boundary values. Mock external dependencies and follow existing test file patterns.

**Integration test implementation** - Test component interactions, API contracts, and database operations with real dependencies. Define test data fixtures, setup/teardown procedures, and assertion validation.

**Regression test creation** - For each bug fix, add tests that fail before the fix and pass after. Document the bug scenario, include reproduction steps in test description, and verify fix prevents recurrence.

## Troubleshooting

<AccordionGroup>
  <Accordion title="Coverage targets not met">
    Scope may be insufficient. Run coverage reports to identify untested code paths, add specific test cases for uncovered branches, and request additional tests for low-coverage modules.
  </Accordion>

  <Accordion title="Tests are flaky and fail intermittently">
    Test isolation may be insufficient. Add proper setup/teardown, eliminate shared state between tests, use deterministic test data, and add timeouts for async operations.
  </Accordion>

  <Accordion title="Mocks don't match real behavior">
    Mock implementations may be outdated. Validate mocks against actual API contracts, use contract testing for external services, and add integration tests to verify real interactions.
  </Accordion>

  <Accordion title="Generated tests import business logic">
    Tests may reimplement production code. Add the [Require Test Coverage](/templates/rules/require-test-coverage) rule to your project on the platform to ensure tests import and use production code exclusively.
  </Accordion>

  <Accordion title="E2E tests are missing">
    E2E scope may not be specified. Explicitly request integration and E2E tests in prompt, define user workflows to test, specify API contracts to validate, and include database state requirements.
  </Accordion>
</AccordionGroup>