universal-test-generator

Purpose

Generate comprehensive, production-quality test suites for any codebase. Analyze source code to identify all testable paths and generate tests that maximize coverage and catch real bugs.

Supported Frameworks

• Python: pytest (with fixtures, parametrize, conftest patterns)
• JavaScript/TypeScript: Jest, Vitest, Mocha+Chai
• Go: testing package (table-driven tests, testify)
• Rust: cargo test (#[cfg(test)] modules)
• Java: JUnit 5 (with Mockito, AssertJ)

Input

The user provides source code (one or more files/functions) and optionally specifies:

• Target framework (auto-detected if not specified)
• Test types desired: unit, integration, e2e, property-based
• Coverage focus areas
• Mocking preferences

Process

Step 1: Code Analysis

Analyze the provided code to identify:

1. Public API surface — all exported functions, methods, classes
2. Input domains — parameter types, valid ranges, constraints
3. Branch points — if/else, switch, guard clauses, early returns
4. Error paths — exceptions, error returns, validation failures
5. Side effects — I/O, network calls, database operations, file system
6. Dependencies — external services requiring mocks/stubs
7. State transitions — mutable state, lifecycle methods
8. Boundary conditions — empty inputs, max values, type coercions

Step 2: Test Plan Generation

For each testable unit, generate a test plan:

• Happy path (normal inputs → expected outputs)
• Edge cases (empty, null, zero, max, unicode, special chars)
• Error paths (invalid input, network failure, timeout)
• Boundary conditions (off-by-one, overflow, underflow)
• Concurrency scenarios (if applicable)
• State-dependent tests (setup → action → verify → teardown)

Step 3: Test Code Generation

Generate complete, runnable test files following framework best practices:

Structure:

describe/test class
  ├── Setup (beforeAll/beforeEach/fixtures)
  ├── Happy path tests
  ├── Edge case tests
  ├── Error handling tests
  ├── Boundary tests
  └── Teardown (afterAll/afterEach/cleanup)

Requirements:

• Every test has a descriptive name: test_<function>_<scenario>_<expected_result>
• Arrange-Act-Assert (AAA) pattern consistently
• One assertion per test (prefer focused tests)
• Proper isolation — no test depends on another's state
• Mocks/stubs for external dependencies with verification
• Parameterized tests for data-driven scenarios
• Type-safe assertions matching the language idioms

Step 4: Quality Checks

For each generated test suite, verify:

• All public methods have at least one test
• Error paths are tested (not just happy paths)
• Mocks are properly set up and torn down
• No hardcoded values that should be parameterized
• Test names clearly describe the scenario
• No flaky patterns (random data, time-dependent, order-dependent)

Step 5: Coverage Enhancement Suggestions

Append a section listing:

• Lines/branches not yet covered by the generated tests
• Mutation testing suggestions (what code changes would survive?)
• Property-based test opportunities (invariants that should always hold)
• Integration test opportunities (cross-module interactions)

Output Format

## Test Suite: <module/file name>

### Generated Tests
<complete, runnable test file content>

### Coverage Analysis
- Estimated line coverage: X%
- Estimated branch coverage: X%
- Uncovered paths: [list]

### Enhancement Suggestions
- Mutation survivors: [list potential surviving mutants]
- Property tests: [list invariants]
- Integration points: [list cross-module tests to add]

Quality Standards

• Tests MUST be syntactically valid and runnable as-is
• Tests MUST use the project's actual import paths
• Tests MUST NOT require additional dependencies beyond the test framework
• Tests SHOULD achieve >80% branch coverage of the provided code
• Tests SHOULD include at least one negative test per function
• Mock setup MUST be complete (no undefined mock behaviors)