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

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.