gsd-build/gsd-2/test

<objective> Generate or run tests for the current project. This skill auto-detects the test framework in use, generates comprehensive tests for source files, or runs existing test suites and analyzes failures.

Accepts optional arguments:

• A file path: generate tests for that source file
• run: run the existing test suite and analyze results
• No arguments: suggest what to test based on recent changes

</objective>

<context> This skill handles test generation and execution across multiple languages and frameworks. It adapts to whatever testing conventions the project already uses rather than imposing new ones. </context>

<quick_start>

<step_1_detect_framework>

Detect the test framework and conventions before doing anything else.

Check these sources in order:

1. package.json (Node/JS/TS projects):

• scripts.test for the test command
• devDependencies for jest, vitest, mocha, ava, tap, node:test, playwright, cypress
• jest or vitest config keys

1. Config files:

• jest.config.*, vitest.config.*, .mocharc.*, ava.config.*
• pytest.ini, pyproject.toml (look for [tool.pytest]), setup.cfg
• go.mod (Go projects use go test by default)
• Cargo.toml (Rust projects use cargo test)

1. Existing test files:

• Scan for *.test.*, *.spec.*, *_test.*, test_*.* files
• Read 1-2 existing test files to understand patterns, imports, assertion style, and structure
• Note the directory structure (co-located tests vs __tests__/ vs tests/ vs test/)

1. Record your findings:

• Framework name and version
• Test file naming convention
• Test file location convention
• Import/require style
• Assertion style (expect, assert, chai, etc.)
• Any custom utilities, fixtures, or helpers used

</step_1_detect_framework>

<step_2_handle_arguments>

Route based on the argument provided.

• File path given -> Go to generate_tests
• "run" given -> Go to run_tests
• No arguments -> Go to suggest_tests

</step_2_handle_arguments>

<generate_tests>

Generate tests for the specified source file.

A. Read and analyze the source file:

• Identify all exported/public functions, classes, methods, and types
• Understand each function's parameters, return types, and side effects
• Note error handling patterns (throws, returns null, returns Result, etc.)
• Identify dependencies that will need mocking

B. Read existing test files in the project (1-2 files minimum):

• Match their import style exactly
• Match their describe/it or test block structure
• Match their assertion patterns
• Match their mock/stub approach
• Use the same test utilities and helpers

C. Generate tests covering:

1. Happy paths: Normal expected inputs produce correct outputs
2. Edge cases:

• Empty inputs (empty string, empty array, null, undefined, zero)
• Boundary values (min/max integers, very long strings)
• Single element collections

1. Error handling:

• Invalid inputs that should throw or return errors
• Missing required parameters
• Type mismatches (if applicable)

1. Async behavior (if the function is async):

• Successful resolution
• Rejection/error cases
• Timeout scenarios (if relevant)

1. Dependencies:

• Mock external dependencies (APIs, databases, file system)
• Verify correct interaction with dependencies (called with right args)

D. Place the test file correctly:

• Follow the project's existing convention for test file location
• Use the project's naming convention (.test.ts, .spec.js, _test.go, test_*.py, etc.)

E. Run the generated tests immediately to verify they pass.

• If tests fail, read the error output carefully
• Fix the test code (not the source code)
• Re-run until all tests pass

</generate_tests>

<run_tests>

Run the existing test suite and analyze results.

A. Determine the test command:

• Check package.json scripts.test for Node projects
• Use pytest for Python projects
• Use go test ./... for Go projects
• Use cargo test for Rust projects
• Fall back to the detected framework's CLI

B. Run the tests:

• Execute the test command
• Capture full output including failures and errors

C. Analyze results:

• Report total passed, failed, skipped counts
• For each failure:
• Identify the failing test name and file
• Show the assertion that failed (expected vs actual)
• Read the relevant source code if needed
• Provide a specific diagnosis of why it failed
• Suggest a concrete fix (is it a test bug or a source bug?)

D. Present a summary:

Test Results: X passed, Y failed, Z skipped
 
Failures:
1. [test name] - [brief diagnosis]
   Fix: [specific suggestion]
 
2. [test name] - [brief diagnosis]
   Fix: [specific suggestion]

</run_tests>

<suggest_tests>

Suggest what to test when no arguments are given.

A. Check recent changes:

Working directory check: if your dispatch context specifies a working directory and pwd does not match it, prefix the git commands below with -C <that path> (e.g. git -C /path/to/worktree diff --name-only HEAD~5).

• Run git diff --name-only HEAD~5 to find recently changed files
• Run git diff --name-only --cached for staged files
• Filter to source files (exclude configs, docs, lockfiles)

B. Check test coverage gaps:

• Find source files that have no corresponding test file
• Prioritize files that were recently modified

C. Present suggestions:

Suggested files to test (based on recent changes and coverage gaps):
 
1. [file path] - modified recently, no test file exists
2. [file path] - modified recently, tests exist but may need updating
3. [file path] - no test coverage found
 
Run `/test <file path>` to generate tests for any of these.
Run `/test run` to run the existing test suite.

</suggest_tests>

</quick_start>

<critical_rules>

1. MATCH EXISTING PATTERNS: Never impose a new test style. Always mirror what the project already does.
2. READ BEFORE WRITING: Always read existing test files before generating new ones.
3. VERIFY GENERATED TESTS: Always run generated tests. Untested test code is unreliable.
4. DON'T MODIFY SOURCE CODE: If generated tests fail, fix the tests, not the source. If the source has a real bug, report it to the user.
5. MOCK EXTERNAL DEPENDENCIES: Never let tests hit real APIs, databases, or file systems unless the project explicitly uses integration tests that way.
6. ONE FILE AT A TIME: Generate tests for one source file per invocation. Keep scope manageable.
7. USE PROJECT DEPENDENCIES: Only use test libraries already installed in the project. Do not add new dependencies without asking.

</critical_rules>

<success_criteria>

Before completing:

• [ ] Test framework and conventions were detected correctly
• [ ] Generated tests match the project's existing test style
• [ ] All generated tests pass when run
• [ ] Tests cover happy paths, edge cases, and error handling
• [ ] Test file is placed in the correct location with the correct naming convention
• [ ] No source code was modified

</success_criteria>