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.