Generate QA Test Cases

Analyze project code and generate comprehensive test cases for QA testing.

Important: Reports should be written in Traditional Chinese.

Arguments

• $ARGUMENTS - Target path to analyze (e.g., libs/mxsecurity/account-page)

Analysis Process

Step 1: Locate and Read Files

Read all relevant files from the target path:

• **/*.ts - TypeScript files (components, services, models)
• **/*.html - Template files
• **/*.model.ts - Data models
• **/*.def.ts - Constants and definitions
• **/*.api.ts - API service files

Step 2: Extract Form Fields and Validation Rules

From TypeScript files, extract:

1. Form Group Definitions

- this.fb.group({...}) or new FormGroup({...}) - this.fb.nonNullable.group({...})

1. Form Controls with Validators

- Validators. usage - OneValidators. usage - Custom validators

1. Conditional Validators

- setValidators() / clearValidators() calls - Dynamic validation logic

Output Format:

## Form Fields and Validation Rules

### Form: {formName}

| Field Name | Type     | Required | Validators                                 | Conditions       |
| ---------- | -------- | -------- | ------------------------------------------ | ---------------- |
| username   | text     | Yes      | required, maxLength(32), pattern(alphanum) | Always           |
| password   | password | Yes      | required, minLength(8), complexity         | Create mode only |

Step 3: Extract Error Messages

From HTML templates, extract:

1. mat-error elements

- Error conditions (*ngIf / @if) - Translation keys for error messages

1. Error message mappings

- hasError('required') → message - hasError('minlength') → message - Custom error keys

1. oneUiFormError directive usage

- Auto-generated error messages

Output Format:

## Validation Error Messages

### Field: {fieldName}

| Validation Rule | Error Condition         | Error Message (Translation Key)     |
| --------------- | ----------------------- | ----------------------------------- |
| required        | `hasError('required')`  | `COMMON.VALIDATION.REQUIRED`        |
| minLength(8)    | `hasError('minlength')` | `COMMON.VALIDATION.MIN_LENGTH`      |
| pattern         | `hasError('pattern')`   | `ACCOUNT.VALIDATION.INVALID_FORMAT` |

Step 4: Extract Conditional Field Visibility

From templates and components, extract:

1. Conditional rendering

- @if (condition) / *ngIf="condition" - [hidden]="condition" - [disabled]="condition"

1. Mode-based visibility

- Create vs Edit mode differences - Role-based field visibility

1. Dependent field logic

- Field A value affects Field B visibility - Cascading selections

Output Format:

## Conditional Field Visibility

### Trigger: {triggerField} = {value}

| Affected Field  | Visibility | Enabled | Notes                            |
| --------------- | ---------- | ------- | -------------------------------- |
| passwordField   | Hidden     | -       | Only shown in create mode        |
| confirmPassword | Shown      | Enabled | Appears when password is entered |

Step 5: Extract API Payload Format

From API service files, extract:

1. POST/PUT endpoints

- Method signatures - Payload interfaces

1. Request payload structure

- Required fields - Optional fields - Field types

1. Data transformations

- Form data → API payload mapping

Output Format:

````markdown

API Payload Format

Endpoint: POST /auth/accountSet

Create Account (mode: 1)

{
  "userName": "string (required)",
  "mode": 1,
  "userEnable": "number (0|1)",
  "authority": "number (1|2)",
  "new_pw": "string (required)",
  "confirm_pw": "string (required)"
}

````

Edit Account (mode: 2)

{
  "userName": "string (required)",
  "mode": 2,
  "userEnable": "number (0|1)",
  "authority": "number (1|2)"
}

````

Step 6: Generate Boundary Test Cases

Based on extracted validation rules, generate test cases:

1. String Length Boundaries

- minLength: test with (min-1), min, (min+1) - maxLength: test with (max-1), max, (max+1)

1. Numeric Range Boundaries

- min: test with (min-1), min, (min+1) - max: test with (max-1), max, (max+1)

1. Pattern Validation

- Valid pattern examples - Invalid pattern examples - Edge cases (empty, special chars)

1. Required Fields

- Empty string - Whitespace only - Null/undefined

Output Format:

## Boundary Test Cases

### Field: username

| Test Case ID | Input Value | Expected Result | Validation Rule |
|--------------|-------------|-----------------|-----------------|
| TC-USER-001 | "" (empty) | Error: Required | required |
| TC-USER-002 | "   " (spaces) | Error: Required | required |
| TC-USER-003 | "a" (1 char) | Error: Min length | minLength(4) |
| TC-USER-004 | "abcd" (4 chars) | Valid | minLength(4) |
| TC-USER-005 | "a".repeat(32) | Valid | maxLength(32) |
| TC-USER-006 | "a".repeat(33) | Error: Max length | maxLength(32) |
| TC-USER-007 | "user@123" | Error: Invalid char | pattern(alphanum) |
| TC-USER-008 | "user_123" | Valid | pattern(alphanum) |
````

### Step 7: Generate Interaction Test Cases

Based on conditional visibility and mode logic:

1. **Mode Switching**
   - Create mode field states
   - Edit mode field states
   - Transition between modes

2. **Dependent Fields**
   - Trigger field changes
   - Expected field state changes

3. **Form Submission**
   - Valid submission
   - Partial validation errors
   - Server error handling

**Output Format:**

Interaction Test Cases

Scenario: Create New Account

## Output

Generate a comprehensive test case document at:
`{target}/domain/src/lib/docs/QA-TEST-CASES.md`

### Document Structure

QA Test Cases - {Feature Name}

Generated: {currentdate} Source: {targetpath}

Table of Contents

1. [Form Fields and Validation Rules](#form-fields-and-validation-rules)
2. [Validation Error Messages](#validation-error-messages)
3. [Conditional Field Visibility](#conditional-field-visibility)
4. [API Payload Format](#api-payload-format)
5. [Boundary Test Cases](#boundary-test-cases)
6. [Interaction Test Cases](#interaction-test-cases)

{Generated sections from Steps 2-7}

## Notes

- Reports should be written in Traditional Chinese
- Focus on extracting actual validation rules from code, not assumptions
- Include translation keys for error messages to help QA verify correct text
- Cross-reference form field names with API payload field names
- Highlight any discrepancies between form validation and API expectations