test-generator

Test Generator

Generate tests following the project's existing test patterns and conventions. Multi-stack aware — adapts to Go, TypeScript, Python, Rust, or any language found in the project.

Detection Strategy

Before generating tests:

1. Identify the language of the target file
2. Find existing tests in the same package/directory (*_test.go, *.test.ts, test_*.py, *_test.rs)
3. Read 2-3 existing test files to learn the project's exact patterns (naming, assertions, mocking style)
4. Match the conventions exactly — do not introduce new test patterns foreign to the project

Test Naming Convention

Use "should [expected behavior] when [condition]" format:

"should return 200 when valid input"
"should return 404 when user does not exist"
"should reject when age is under 18"
"should allow re-acquire when previous lock expired"

Language-Specific Patterns

Go

• Table-driven tests with t.Run(tt.name, ...)
• httptest.NewRequest + httptest.NewRecorder for HTTP handlers
• Mock interfaces, not concrete types (function-field mocks or generated mocks)
• Test file: same package, _test.go suffix
• Use t.Parallel() on independent test cases
• t.Fatalf for setup failures, t.Errorf for assertion failures
• Integration tests: testing.Short() skip or env var guard

TypeScript/JavaScript

• Test runner: detect from package.json (vitest, jest, mocha)
• describe/it blocks with clear descriptions
• Mock external dependencies (API calls, timers)
• Use beforeEach for setup, avoid shared mutable state
• Assert with framework's native matchers

Python

• pytest with descriptive function names (test_should_return_404_when_not_found)
• @pytest.fixture for setup, @pytest.mark.parametrize for table-driven
• Mock with unittest.mock.patch or pytest-mock
• Separate unit tests from integration tests (tests/unit/, tests/integration/)

Edge Case Heuristics

When generating tests, always include edge cases from this checklist: