Unit Testing Skill
Write comprehensive unit tests with full coverage: happy paths, edge cases, and error conditions.
Core Principles
- Test behavior, not implementation - Tests verify what code does, not how
- One assertion concept per test - Each test validates a single logical behavior
- Arrange-Act-Assert structure - Setup, execute, verify
- Descriptive test names - Name describes scenario and expected outcome
- Independent tests - No test depends on another's state or execution order
- Fast tests - Mock expensive operations (network, disk, databases) unless integration testing
Workflow
0. MANDATORY: Use context7 Before Writing Tests
CRITICAL: Before writing ANY tests, use context7 to look up current testing framework documentation and best practices.
Always use context7 to verify:
- Testing framework APIs (Jest, Vitest, pytest, etc.)
- Assertion syntax and available matchers
- Mocking/stubbing patterns
- Testing library utilities (React Testing Library, etc.)
- Framework-specific best practices
Process:
- Identify testing framework and libraries in use
- Use
context7 resolve <framework>for each - Query relevant topics: assertions, mocking, async testing, etc.
- Review docs before writing test code
Example:
context7 resolve vitest
context7 get-library-docs --library vitest --topic "mocking"
context7 resolve @testing-library/react
context7 get-library-docs --library @testing-library/react --topic "async"Workflow Steps
- Use context7 for testing framework docs - Look up current API and patterns
- Analyze the code - Identify public interfaces, dependencies, edge cases, error conditions
- Determine test scope - Unit tests for functions/classes, integration tests for interactions
- Check existing structure - Follow project's existing test organization patterns
- Select appropriate framework - See language-specific references below
- Write comprehensive tests covering:
- Happy path (expected inputs produce expected outputs) - Edge cases (empty inputs, boundaries, null/None values) - Error conditions (invalid inputs, exceptions, failure modes) - State changes (side effects, mutations)
context7 Usage by Language/Framework
Before writing tests, use context7 to look up documentation for:
| Language/Framework | context7 Libraries to Query |
|---|---|
| JavaScript/React | react, vitest or jest, @testing-library/react |
| Python | pytest, relevant libraries being tested |
| R | testthat, tidyverse |
| Rust | rust (built-in testing) |
| Go | go (testing package) |
| C++ | googletest or gtest |
| Node.js/Express | express, supertest, jest |
Common topics to query:
- "mocking", "assertions", "async testing", "setup teardown"
- "matchers", "fixtures", "test coverage", "integration tests"
Language References
Select the appropriate reference based on the code being tested:
| Language/Tool | Reference | Framework |
|---|---|---|
| Python | python.md | pytest |
| JavaScript | javascript.md | Jest / Vitest |
| R | r.md | testthat |
| Rust | rust.md | built-in #[test] |
| Go | go.md | testing + testify |
| C++ | cpp.md | Google Test |
| SQL (PostgreSQL) | sql.md | pgTAP |
| Bash | bash.md | bats-core |
| Ansible | ansible.md | Molecule + ansible-lint |
| Kubernetes/Kustomize | kubernetes.md | kubeconform + conftest |
| Docker | docker.md | hadolint + container-structure-test |
Test Organization
Follow each language's conventions. When a project has existing tests, match their structure.
Mocking Strategy
Mock external dependencies based on context:
- Always mock: Network calls, external APIs, system time
- Consider mocking: Databases (use test DB or mock based on test type), file system
- Rarely mock: Pure functions, data transformations
Coverage Targets
Aim for comprehensive coverage:
- All public functions/methods
- All code branches (if/else, match arms, error handlers)
- Boundary conditions
- Error handling paths
REMINDER: Always Use context7
Before writing any test code:
- Use context7 to look up the testing framework's current API
- Verify assertion syntax and available matchers
- Check mocking/stubbing best practices
- Review async testing patterns if needed
Never write tests from memory alone - always verify with current documentation using context7.