# Create Test

> Generate or update unit tests for a component following project testing conventions

- Skill: `sap/create-test` (Agent Skill)
- Install (CLI): `npx skillmds@latest add sap/create-test`
- Raw SKILL.md: https://api.skillmd.com/api/skills/sap/create-test/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: sap (https://skillmd.com/u/sap)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/sap/create-test

---


# Create/Update Tests: $ARGUMENTS

If `$ARGUMENTS` is empty, ask the user for a component path before proceeding.

## Phase 1: Analyze the component

Read the component file at `$ARGUMENTS`. Extract:

- All `input()` / `input.required()` and `@Input()` declarations with types and defaults
- All `output()` and `@Output()` declarations with event types
- All `model()` declarations
- All public/protected methods
- Template interactions (click handlers, form bindings, conditional rendering)
- Host bindings and listeners
- Injected dependencies

## Phase 2: Check existing tests

Look for an existing `.spec.ts` file alongside the component. If found, read it and identify:

- What is already covered
- What is missing based on the component analysis
- Any patterns that violate project conventions (see below)

## Phase 3: Generate/update tests

### Conventions to follow

**Structure:**

- One `describe` block per component
- Nested `describe` for each feature group (inputs, outputs, interactions, a11y)
- `it` descriptions should be user-focused: "should display label when label input is set"
- AAA pattern: Arrange → Act → Assert

**Signal inputs:**

- Use `fixture.componentRef.setInput('inputName', value)` — never assign directly
- Call `fixture.detectChanges()` after setting inputs
- Test default values by checking initial render without setting input

**Imports:**

- Individual component/directive imports — no deprecated `*Module` classes
- Import only what the test needs

**Test components:**

- Use unique names: `MenuTestComponent`, not `TestComponent`
- Keep test component templates minimal — only what's needed for the test

**What to test:**

- Default rendering
- Each input affects the component as expected
- Outputs emit correct events on user interaction
- Two-way bindings (`model()`) update in both directions
- Keyboard navigation where applicable
- Disabled state behavior
- Edge cases: empty strings, null values, boundary numbers

**What NOT to test:**

- TypeScript-prevented scenarios (passing wrong types)
- Angular DI-prevented scenarios (missing required providers)
- Private methods or internal signal values
- Implementation details (internal CSS classes unless they're the public API)

### Output format

Generate the complete test file content. If updating an existing file, show only the additions/changes needed.

## Phase 4: Verify

```bash
yarn format
nx run <library>:test --testfile=<spec-file> --skip-nx-cache
```

Format the code first, then run tests. Report test results. If failures occur, diagnose and fix.