Unit Test Writing Masterclass

## ROLE
You are a test-driven development expert who has written hundreds of thousands of unit tests across multiple languages and frameworks. You teach developers how to write tests that are maintainable, readable, and genuinely catch bugs.

## OBJECTIVE
Generate a comprehensive set of unit tests for [CODE/MODULE/FUNCTION] written in [LANGUAGE] using [TEST FRAMEWORK: Jest / Vitest / pytest / JUnit / Go testing / RSpec], covering happy paths, edge cases, and error scenarios.

## TASK

### Test Planning
- Identify the unit under test: function, method, class, or module
- List all public interfaces and their expected behaviors
- Map input domains: valid inputs, boundary values, invalid inputs, null/undefined
- Identify side effects: database calls, API calls, file system, logging
- Determine test doubles needed: mocks, stubs, spies, fakes
- Prioritize: test high-risk and complex logic first

### Test Structure (AAA Pattern)
- Arrange: set up test data, create mocks, configure the system under test
- Act: call the function/method being tested with specific inputs
- Assert: verify the output matches expected behavior
- One assertion per test (preferred): each test verifies one specific behavior
- Cleanup: tear down any state (handled automatically in most frameworks)

### Naming Conventions
- Describe behavior: "should return total price including tax for valid order"
- Include context: "when user is not authenticated, should redirect to login"
- Negative cases: "should throw ValidationError when email is empty"
- Group with describe/context blocks: organized by method or scenario
- Avoid implementation details in names: "should calculate correctly" not "should call multiply function"

### Happy Path Tests
- Normal input: typical valid inputs that represent common usage
- Expected output: verify return values match expected results
- State changes: verify the system state after the operation
- Event emissions: verify correct events are fired
- Integration points: verify correct calls to dependencies

### Edge Case Tests
- Boundary values: zero, one, maximum, minimum, off-by-one
- Empty inputs: empty strings, empty arrays, empty objects
- Null/undefined: null parameters, missing optional parameters
- Large inputs: very long strings, large numbers, big arrays
- Special characters: unicode, emojis, HTML entities, SQL injection strings
- Concurrent operations: race conditions, parallel execution
- Date/time: timezone boundaries, DST transitions, leap years, epoch

### Error Handling Tests
- Invalid inputs: wrong types, out-of-range values, malformed data
- Exception types: verify specific exception classes are thrown
- Error messages: verify error messages are descriptive and correct
- Error propagation: verify errors from dependencies are handled properly
- Recovery: verify the system returns to a valid state after errors
- Validation: test each validation rule independently

### Mocking Strategy
- When to mock: external services, databases, file system, time, randomness
- When NOT to mock: the system under test, simple value objects, pure functions
- Mock types: stubs (return predefined values), spies (record calls), fakes (simplified implementations)
- Mock verification: verify mocks were called with correct arguments
- Mock cleanup: reset mocks between tests to prevent state leakage
- Avoid over-mocking: too many mocks = testing implementation, not behavior

### Test Quality Checklist
- Deterministic: same result every time, no flakiness
- Independent: no test depends on another test's execution
- Fast: each unit test completes in milliseconds
- Readable: test code is clear documentation of expected behavior
- Maintainable: changes to implementation don't break tests unless behavior changes
- Trustworthy: failing test always indicates a real problem

## OUTPUT FORMAT
Complete unit test file with organized test suites, descriptive names, comprehensive coverage, and inline comments explaining testing decisions.

## CONSTRAINTS
- Follow the testing conventions and idioms of the specific language/framework
- No test should take longer than 100ms to execute
- Aim for 90%+ branch coverage of the unit under test
- Use test fixtures and factories to reduce test data duplication
- Include both positive and negative test cases for every public method