tests-new

Reviews the feature you just built and adds missing test coverage. Focuses on behavior that matters — not coverage metrics. Use after completing a feature to identify untested code paths, edge cases, and risk areas.

Safety Notice

This listing is imported from skills.sh public index metadata. Review upstream SKILL.md and repository scripts before running.

Copy this and send it to your AI assistant to learn

Install skill "tests-new" with this command: npx skills add skinnyandbald/fish-skills/skinnyandbald-fish-skills-tests-new

New Tests for Recent Work

Review recent changes and add missing test coverage where it matters.

Instructions

Step 1: Identify Recent Changes

Run git diff HEAD~1 (or git diff main...HEAD if on a branch) to find what changed. If no git changes, ask the user which files to cover.

Focus on:

  • New functions, methods, or components
  • Changed behavior in existing code
  • New API endpoints or routes
  • Modified business logic

Step 2: Audit Existing Coverage

For each changed file, check if corresponding tests exist:

  • src/foo.ts → look for src/foo.test.ts, tests/foo.test.ts, __tests__/foo.test.ts
  • Follow the project's test file convention

Classify each changed function/component:

StatusMeaning
UntestedNo test file or no tests for this function
Under-testedTests exist but miss important paths
CoveredTests adequately cover the behavior

Step 3: Prioritize by Risk

Don't test everything — test what matters. Prioritize:

  1. Complex logic — conditionals, loops, state machines, calculations
  2. Error paths — what happens when things fail
  3. Data transformations — parsing, formatting, mapping
  4. Integration boundaries — API calls, database queries, external services
  5. User-facing behavior — things that break the experience if wrong

Skip:

  • Simple getters/setters
  • Pure pass-through functions
  • Framework boilerplate
  • Code that's already well-covered

Step 4: Write Tests

Follow the project's existing test patterns (framework, assertion style, file structure, mocking approach). Read 1-2 existing test files first to match conventions.

For each test:

  • Name describes behavior, not implementation: "returns empty array when no results found" not "test getResults"
  • Arrange-Act-Assert structure
  • One behavior per test — if a test name has "and", split it
  • Real edge cases: empty input, null/undefined, boundary values, concurrent access, error responses

Step 5: Verify

Run the new tests to ensure they pass. If any fail, that's a potential bug — flag it rather than deleting the test.

Step 6: Report

## New Test Coverage

**Files analyzed:** [count]
**Tests added:** [count]
**Potential bugs found:** [count, if any]

### Added
- `[test file]`: [what behaviors are now covered]

### Skipped (adequate coverage)
- `[file]`: already covered by [test file]

### Potential Bugs
- `[test name]`: expected [X] but got [Y] — [file:line]

Source Transparency

This detail page is rendered from real SKILL.md content. Trust labels are metadata-based hints, not a safety guarantee.

Related Skills

Related by shared tags or category signals.

General

counselors

No summary provided by upstream source.

Repository SourceNeeds Review
General

simplify-parallel

No summary provided by upstream source.

Repository SourceNeeds Review
General

deepproduct

No summary provided by upstream source.

Repository SourceNeeds Review
General

pr-resolution

No summary provided by upstream source.

Repository SourceNeeds Review