code-testing

Files (1)

• SKILL.md

SKILL.md (first lines)

!`bash ${CLAUDE_SKILL_DIR}/../../hooks/read-state.sh session-state`

<preflight-guard>
STOP. Before executing this skill, check: does .sweetclaude/state/sweetclaude.yaml or .sweetclaude/state/phase.yaml exist in the project directory? If NEITHER, do not proceed. Tell the user: "This project is not set up for SweetClaude. Running the pre-flight check now." Then invoke the sweetclaude master skill (Skill tool, skill: "sweetclaude:master") and run its pre-flight. Return here only after the pre-flight passes.
</preflight-guard>

# Code Testing

## Step 1: Choose what to run

Present this menu and ask the user to pick one or more:

```
What do you want to run? (pick one or several)

  1. Test suite      — run tests, report pass/fail
  2. Mutation        — verify tests actually catch faults
  3. Security        — review code for auth, injection, and secrets issues
  4. PR pre-check    — final quality gate before opening a PR
```

Accept any combination: "1", "1 3", "all", "1 2 3 4", "security", "test suite and pr", etc. Parse the intent.

If `$ARGUMENTS` was passed (e.g. `/sweetclaude:build code-testing security`), skip the menu and use that as the selection.

Run selected checks in this order: test suite → mutation → security → PR pre-check. Complete each before starting the next.

---

## Test Suite

Run tests for: $ARGUMENTS (package name, service name, or "all")

**Process:**

1. Read the project's test command from CLAUDE.md or `testing.test_command` in `.sweetclaude/state/project.yaml`. If neither names one, work it out from the project (pytest configuration, a `package.json` test script, a Makefile target) and record it in `.sweetclaude/state/project.yaml` without overwriting other keys, so the auto-test-runner hook runs the same command after source edits:

   ```yaml
   testing:
     test_command: <command that runs the full suite>
   ```

2. Run the tests. If a package or service was specified, scope the run. Otherwise run the full suite.

3. Report concisely:

   If all pass:
   ```
   ✓ {N} tests passed, 0 failed
   ```

   If any fail:
   ```
   ✗ {N} passed, {M} failed

   Failures:
   - {test name} — {file}:{line}
     Expected: {expected}
     Received: {actual}
   ```

4. Do not dump full stdout/stderr. Summarize failures only. The user can ask for verbose output.

**Rules:**
- This check reports. It does not fix. For fixes, use `code-tdd` or `code-issue`.
- If the test command is not configured, say so and ask the user to add it to CLAUDE.md.

---

## Mutation Testing

Verify that tests detect faults, not just achieve coverage.

**Process:**

1. Detect language and select tool:
   - JavaScript/TypeScript: Stryker Mutator (`npx stryker run`)
   - Python: mutmut (`mutmut run`)
   - Go: gremlins (`gremlins unleash`)
   - Rust: cargo-mutants (`cargo mutants`)
   - Other: mewt (language-agnostic, Trail of Bits)
   - If no tool is available for the detected language, report and skip.

2. Scope to changed files only. Use `git diff` to identify changed source files.

3. Run the mutation testing tool scoped to those files.

4. Report results:
   - Mutation score (killed / total mutants)
   - List of surviving mutants: file, line, mutation type, what changed
   - For each survivor: is the gap meaningful or trivial?

5. Recommend action:
   - Score > 80%: "✓ Tests are solid. Surviving mutants are [trivial/edge cases]."
   - Score 60–80%: "⚠ Meaningful gaps. Add tests for: [list]"
   - Score < 60%: "✗ Tests are not catching real faults. Add tests before merging."

**Rules:**
- Never modify source code to improve mutation score. Only add tests.
- Scope to changed files only — full-codebase mutation is too slow.

---

## Security Review

Review code changes for security issues.

**Scope:** If $ARGUMENTS specifies files or a PR, review those. Otherwise review staged changes or recent commits.

**Checklist:**

For each file in scope:

*Authentication & Authorization*
- [ ] Auth checks present on all endpoints/handlers that need them
- [ ] Authorization scoped correctly (tenant boundaries, role checks)
- [ ] No auth bypass paths (direct object reference, parameter manipulation)
- [ ] Session handling follows project patterns

From carson-sweet/sweetclaude, AGPL-3.0.

More from carson-sweet/sweetclaude