unit-testing

1. Test behavior, not implementation - Tests verify what code does, not how
2. One assertion concept per test - Each test validates a single logical behavior
3. Arrange-Act-Assert structure - Setup, execute, verify
4. Descriptive test names - Name describes scenario and expected outcome
5. Independent tests - No test depends on another's state or execution order
6. Fast tests - Mock expensive operations (network, disk, databases) unless integration testing

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:

1. Identify testing framework and libraries in use
2. Use context7 resolve for each
3. Query relevant topics: assertions, mocking, async testing, etc.
4. 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

1. Use context7 for testing framework docs - Look up current API and patterns
2. Analyze the code - Identify public interfaces, dependencies, edge cases, error conditions
3. Determine test scope - Unit tests for functions/classes, integration tests for interactions
4. Check existing structure - Follow project's existing test organization patterns
5. Select appropriate framework - See language-specific references below
6. 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)

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"

Select the appropriate reference based on the code being tested:

| Language/Tool | Reference | Framework |

|---------------|-----------|-----------|

| Python | [python.md](references/python.md) | pytest |

| JavaScript | [javascript.md](references/javascript.md) | Jest / Vitest |

| R | [r.md](references/r.md) | testthat |

| Rust | [rust.md](references/rust.md) | built-in #[test] |

| Go | [go.md](references/go.md) | testing + testify |

| C++ | [cpp.md](references/cpp.md) | Google Test |

| SQL (PostgreSQL) | [sql.md](references/sql.md) | pgTAP |

| Bash | [bash.md](references/bash.md) | bats-core |

| Ansible | [ansible.md](references/ansible.md) | Molecule + ansible-lint |

| Kubernetes/Kustomize | [kubernetes.md](references/kubernetes.md) | kubeconform + conftest |

| Docker | [docker.md](references/docker.md) | hadolint + container-structure-test |

Follow each language's conventions. When a project has existing tests, match their structure.

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

Aim for comprehensive coverage:

• All public functions/methods
• All code branches (if/else, match arms, error handlers)
• Boundary conditions
• Error handling paths

Before writing any test code:

1. Use context7 to look up the testing framework's current API
2. Verify assertion syntax and available matchers
3. Check mocking/stubbing best practices
4. Review async testing patterns if needed

Never write tests from memory alone - always verify with current documentation using context7.