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.
1---2name: unit-testing3description: Write comprehensive unit tests for code. Use when asked to (1) write tests for new or existing code, (2) add unit tests, (3) test a function/module/class, (4) verify code still works after changes, (5) create test coverage, or when phrases like "write tests", "add tests", "test this", "make sure this works" appear. Supports Python, JavaScript, R, Rust, Go, C++, SQL, Bash, Ansible, Kubernetes/Kustomize, Docker, and Docker Compose.4---56# Unit Testing Skill78Write comprehensive unit tests with full coverage: happy paths, edge cases, and error conditions.910## Core Principles11121. **Test behavior, not implementation** - Tests verify what code does, not how132. **One assertion concept per test** - Each test validates a single logical behavior143. **Arrange-Act-Assert structure** - Setup, execute, verify154. **Descriptive test names** - Name describes scenario and expected outcome165. **Independent tests** - No test depends on another's state or execution order176. **Fast tests** - Mock expensive operations (network, disk, databases) unless integration testing1819## Workflow2021### 0. MANDATORY: Use context7 Before Writing Tests2223**CRITICAL**: Before writing ANY tests, use context7 to look up current testing framework documentation and best practices.2425**Always use context7 to verify:**26- Testing framework APIs (Jest, Vitest, pytest, etc.)27- Assertion syntax and available matchers28- Mocking/stubbing patterns29- Testing library utilities (React Testing Library, etc.)30- Framework-specific best practices3132**Process:**331. Identify testing framework and libraries in use342. Use `context7 resolve <framework>` for each353. Query relevant topics: assertions, mocking, async testing, etc.364. Review docs before writing test code3738**Example:**39```40context7 resolve vitest41context7 get-library-docs --library vitest --topic "mocking"42context7 resolve @testing-library/react43context7 get-library-docs --library @testing-library/react --topic "async"44```4546### Workflow Steps47481. **Use context7 for testing framework docs** - Look up current API and patterns492. **Analyze the code** - Identify public interfaces, dependencies, edge cases, error conditions503. **Determine test scope** - Unit tests for functions/classes, integration tests for interactions514. **Check existing structure** - Follow project's existing test organization patterns525. **Select appropriate framework** - See language-specific references below536. **Write comprehensive tests** covering:54 - Happy path (expected inputs produce expected outputs)55 - Edge cases (empty inputs, boundaries, null/None values)56 - Error conditions (invalid inputs, exceptions, failure modes)57 - State changes (side effects, mutations)5859## context7 Usage by Language/Framework6061Before writing tests, use context7 to look up documentation for:6263| Language/Framework | context7 Libraries to Query |64|-------------------|----------------------------|65| JavaScript/React | `react`, `vitest` or `jest`, `@testing-library/react` |66| Python | `pytest`, relevant libraries being tested |67| R | `testthat`, `tidyverse` |68| Rust | `rust` (built-in testing) |69| Go | `go` (testing package) |70| C++ | `googletest` or `gtest` |71| Node.js/Express | `express`, `supertest`, `jest` |7273**Common topics to query:**74- "mocking", "assertions", "async testing", "setup teardown"75- "matchers", "fixtures", "test coverage", "integration tests"7677## Language References7879Select the appropriate reference based on the code being tested:8081| Language/Tool | Reference | Framework |82|---------------|-----------|-----------|83| Python | [python.md](references/python.md) | pytest |84| JavaScript | [javascript.md](references/javascript.md) | Jest / Vitest |85| R | [r.md](references/r.md) | testthat |86| Rust | [rust.md](references/rust.md) | built-in #[test] |87| Go | [go.md](references/go.md) | testing + testify |88| C++ | [cpp.md](references/cpp.md) | Google Test |89| SQL (PostgreSQL) | [sql.md](references/sql.md) | pgTAP |90| Bash | [bash.md](references/bash.md) | bats-core |91| Ansible | [ansible.md](references/ansible.md) | Molecule + ansible-lint |92| Kubernetes/Kustomize | [kubernetes.md](references/kubernetes.md) | kubeconform + conftest |93| Docker | [docker.md](references/docker.md) | hadolint + container-structure-test |9495## Test Organization9697Follow each language's conventions. When a project has existing tests, match their structure.9899## Mocking Strategy100101Mock external dependencies based on context:102- **Always mock**: Network calls, external APIs, system time103- **Consider mocking**: Databases (use test DB or mock based on test type), file system104- **Rarely mock**: Pure functions, data transformations105106## Coverage Targets107108Aim for comprehensive coverage:109- All public functions/methods110- All code branches (if/else, match arms, error handlers)111- Boundary conditions112- Error handling paths113114## REMINDER: Always Use context7115116**Before writing any test code:**1171. Use context7 to look up the testing framework's current API1182. Verify assertion syntax and available matchers1193. Check mocking/stubbing best practices1204. Review async testing patterns if needed121122**Never write tests from memory alone** - always verify with current documentation using context7.