testing_skill

Overview

This skill validates test file conventions for TypeScript projects: setup functions, factory patterns, test organization, type testing, and naming. It helps enforce clear, maintainable *.test.ts files so tests document behavior, are composable, and resist accidental type or state leaks.

How this skill works

The skill inspects test files for required top-of-file JSDoc summaries, section headers for long files, and sensible file splitting by behavioral aspect. It checks for a single setup() pattern that returns a destructured object, discourages beforeEach state, enforces behavior-first test names, and verifies proper use of @ts-expect-error and no as any bypasses. It reports concrete suggestions to rewrite tests that violate these conventions.

When to use it

• When creating or refactoring any *.test.ts file to match project conventions
• When adding or changing shared test setup, factories, or mocks
• When writing or reviewing type tests (.types.test.ts) and negative type assertions
• When splitting a large test file into focused concerns (CRUD vs sync vs types)
• When enforcing consistent naming and avoiding brittle nested describe/beforeEach patterns

Best practices

• Start each test file with a JSDoc block summarizing what is tested and key behaviors
• Use a plain setup() that returns a destructured object; call it per test and avoid describe-level mutable state
• Name tests as explicit behavior assertions: action + outcome [+ condition], no filler words
• Keep negative type tests in dedicated files, use one @ts-expect-error per assertion with explanatory comments
• Prefer flat test() calls and composable setup variants instead of deep describe/beforeEach nesting
• Define shared, stateless schemas at module scope; keep stateful objects inside setup()

Example use cases

• Converting tests that use beforeEach assignment into per-test setup() calls returning named values
• Splitting a 700-line test file into module.test.ts, module.sync.test.ts, and module.types.test.ts
• Adding @ts-expect-error checks in a .types.test.ts file to verify compile-time rejections
• Renaming vague tests like 'should work' into descriptive behavior assertions before merging
• Removing incorrect as any usages and replacing them with typed mocks or public-API tests