Skip to main content
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.
Blitzy automatically provides acceptable unit test coverage. You must explicitly specify integration, E2E, and functional test requirements in your prompts with clear scope definition.

Ready to add testing?

Use the Add Testing Template to get started with a structured prompt
Jump to: When to Use | Prompt Structure | Key Considerations | Common Patterns | Troubleshooting

​
When to Use This Approach

Bring modules up to 80%+ coverage targets with unit tests that cover success paths, error conditions, and boundary values.

​
Prompt Structure

Follow the 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

Coverage Targets Drive Scope

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.

Mocking Strategy Affects Isolation

Define which external dependencies to mock (APIs, databases, services) and which to use in integration tests. Improper mocking creates brittle tests or insufficient validation.

Test Patterns Ensure Consistency

Reference existing test files showing preferred patterns (describe blocks, assertion style, fixture usage). Inconsistent test patterns make test suites harder to maintain.

E2E Scope Requires Explicit Definition

Integration and E2E tests need explicit scope definition including user workflows, API contracts, and database states. Without explicit scope, Blitzy generates only unit tests.

​
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

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.
Test isolation may be insufficient. Add proper setup/teardown, eliminate shared state between tests, use deterministic test data, and add timeouts for async operations.
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.
Tests may reimplement production code. Add the Require Test Coverage rule to your project on the platform to ensure tests import and use production code exclusively.
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.