/test-writer

name: memstack-development-test-writer
description: "Use this skill when the user says 'write tests', 'add tests', 'test coverage', 'unit tests', 'integration tests', 'component tests', 'mocking', 'edge cases', or needs to generate tests with proper mocking and edge case coverage. Do NOT use for refactoring plans or database migrations."
version: 1.0.0
license: "Proprietary, MemStack™ Pro by CW Affiliate Investments LLC. See LICENSE.txt"

Test Writer: Generating test suite...

*Generates comprehensive test suites with unit, integration, and e2e tests, proper mocking strategies, edge case coverage, naming conventions, and CI integration patterns.*

Activation

When this skill activates, output:

`Test Writer: Generating test suite...`

Then execute the protocol below.

Context Guard

| Context | Status | |---------|--------| | User says "write tests", "add tests", "test coverage" | ACTIVE | | User says "unit tests", "integration tests", "component tests", "e2e tests" | ACTIVE | | User says "mocking", "edge cases", "test this function" | ACTIVE | | User wants to refactor existing code | DORMANT: use Refactor Planner | | User wants to change database schema | DORMANT: use Migration Planner |

Common Mistakes

| Mistake | Why It's Wrong | |---------|---------------| | "Testing implementation, not behavior" | Tests that break when you refactor internals are brittle. Test WHAT it does, not HOW. | | "No edge cases" | Happy path tests catch 20% of bugs. Boundaries, nulls, empty inputs, and error paths catch the rest. | | "Mocking everything" | Over-mocking creates tests that pass but don't catch real bugs. Mock boundaries, not internals. | | "Test names like test1, test2" | Names should describe behavior: "returns empty array when no items match filter". Self-documenting tests. | | "No test isolation" | Tests that depend on each other or shared state create flaky test suites that nobody trusts. |

Protocol

Step 1: Gather Test Requirements

If the user hasn't provided details, ask:

> 1. **Target**: what code needs tests? (function, class, module, API endpoint) > 2. **Language/framework**: what tech stack? (JS/TS + Jest/Vitest, Python + pytest, Go, etc.) > 3. **Test level**: unit, integration, e2e, or all three? > 4. **Current coverage**: any existing tests? What percentage? > 5. **Priority**: critical paths first, or comprehensive coverage?

Step 2: Analyze the Code Under Test

Before writing tests, understand the target:

**Function/method analysis:**

| Property | Value | |----------|-------| | **Inputs** | [Parameters, types, optional/required] | | **Outputs** | [Return type, side effects, thrown exceptions] | | **Dependencies** | [External calls: DB, API, file system, other modules] | | **State changes** | [What mutates: database records, cache, global state] | | **Branching paths** | [Number of if/else/switch branches] | | **Error conditions** | [What can fail and how it's handled] |

**Dependency map:**

[Target Function]
  ├── [Dependency 1]: mock? [Yes: external / No: pure]
  ├── [Dependency 2]: mock? [Yes: external / No: pure]
  └── [Dependency 3]: mock? [Yes: external / No: pure]

**Mock decision rule:**

• **Mock** external boundaries: databases, APIs, file system, network, time
• **Don't mock** pure functions, internal utilities, simple data transformations
• **Sometimes mock** sibling modules (mock for unit tests, real for integration)

Step 3: Design Test Cases

**Coverage strategy: identify all test scenarios:**

**Happy path tests:**

| # | Scenario | Input | Expected Output | |---|---------|-------|----------------| | 1 | [Normal case with typical input] | [Input] | [Output] | | 2 | [Normal case with different valid input] | [Input] | [Output] |

**Edge case tests:**

| # | Category | Scenario | Input | Expected Output | |---|---------|---------|-------|----------------| | 1 | **Boundaries** | Minimum valid value | [Input] | [Output] | | 2 | **Boundaries** | Maximum valid value | [Input] | [Output] | | 3 | **Boundaries** | Exactly at limit | [Input] | [Output] | | 4 | **Empty** | Empty string / array / object | `""` / `[]` / `{}` | [Output] | | 5 | **Null/Undefined** | Null input | `null` | [Output or error] | | 6 | **Type coercion** | Unexpected type | `"123"` vs `123` | [Output] | | 7 | **Large input** | Very large dataset | [X items] | [Output / perf] | | 8 | **Unicode** | Special characters | `"café ñ 中文"` | [Output] | | 9 | **Concurrent** | Race condition scenario | [Parallel calls] | [Consistent state] |

**Error path tests:**

| # | Error Condition | Input | Expected Behavior | |---|----------------|-------|-------------------| | 1 | Invalid input | [Bad input] | Throws [ErrorType] with message | | 2 | Dependency failure | [DB timeout] | Returns fallback or propagates error | | 3 | Permission denied | [Unauthorized] | Returns 403 / throws AuthError | | 4 | Not found | [Missing resource] | Returns null or throws NotFoundError |

Step 4: Write the Tests

**Test file naming conventions:**

| Framework | Convention | Example | |-----------|----------|---------| | Jest / Vitest | `[name].test.ts` or `[name].spec.ts` | `userService.test.ts` | | pytest | `test_[name].py` | `test_user_service.py` | | Go | `[name]_test.go` | `user_service_test.go` | | JUnit | `[Name]Test.java` | `UserServiceTest.java` |

**Test naming conventions:**

| Style | Pattern | Example | |-------|---------|---------| | **Behavior-driven** | `should [expected] when [condition]` | `should return empty array when no items match filter` | | **Given-When-Then** | `given [state] when [action] then [result]` | `given expired token when authenticating then throws AuthError` | | **Method-focused** | `[method], [scenario], [expected]` | `calculateTotal, with discount: applies percentage reduction` |

**Test structure template (JavaScript/TypeScript):**

describe('[ModuleName]', () => {
  // Setup shared across tests in this block
  let dependency: MockType;