Test Helper

分析程式碼 → 設計測試策略 → 產出測試案例

核心理念

┌─────────────────────────────────────────────────────────────────┐
│  測試不是事後想到才做，而是開發流程的一部分                     │
│                                                                 │
│  本 Skill 職責：                                                │
│  • 分析程式碼，識別需要測試的點                                 │
│  • 設計測試策略                                                 │
│  • 產出測試案例建議                                             │
│  • 評估測試覆蓋率                                               │
└─────────────────────────────────────────────────────────────────┘

測試策略

測試金字塔

                    ┌───────┐
                    │  E2E  │  少量，驗證完整流程
                    ├───────┤
                ┌───┤ 整合  ├───┐  中量，驗證模組協作
                │   ├───────┤   │
            ┌───┴───┤ 單元  ├───┴───┐  大量，驗證個別函式
            └───────┴───────┴───────┘

測試類型

測試設計流程

Step 1: 分析目標程式碼

檢查：
1. 有哪些公開函式/方法？
2. 有哪些輸入/輸出？
3. 有哪些邊界條件？
4. 有哪些錯誤情況？

Step 2: 設計測試案例

test_cases:
  - name: "正常流程"
    description: "驗證基本功能"
    input: "正常輸入"
    expected: "預期輸出"

  - name: "邊界條件"
    description: "驗證極限情況"
    input: "邊界值"
    expected: "正確處理"

  - name: "錯誤處理"
    description: "驗證錯誤情況"
    input: "無效輸入"
    expected: "適當的錯誤訊息"

Step 3: 輸出測試計劃

test_plan:
  target: "src/api/user.js"
  framework: "jest"
  strategy: "unit"

  test_cases:
    - name: "should create user with valid data"
      type: "happy_path"
      priority: "high"

    - name: "should reject invalid email"
      type: "validation"
      priority: "high"

    - name: "should handle database error"
      type: "error_handling"
      priority: "medium"

  coverage_target:
    statements: 80
    branches: 75
    functions: 90
    lines: 80

測試案例模板

Jest 範例

describe('UserService', () => {
  describe('createUser', () => {
    // Happy path
    it('should create user with valid data', async () => {
      const userData = { name: 'John', email: 'john@example.com' };
      const result = await userService.createUser(userData);
      expect(result.id).toBeDefined();
      expect(result.name).toBe('John');
    });

    // Validation
    it('should reject invalid email', async () => {
      const userData = { name: 'John', email: 'invalid' };
      await expect(userService.createUser(userData))
        .rejects.toThrow('Invalid email');
    });

    // Edge case
    it('should handle empty name', async () => {
      const userData = { name: '', email: 'john@example.com' };
      await expect(userService.createUser(userData))
        .rejects.toThrow('Name is required');
    });
  });
});

最小範例

用戶：幫這個函式寫測試
AI：

1. 分析函式：calculateTotal(items)
2. 識別測試點：
   - 正常計算
   - 空陣列
   - 負數價格
   - 大量項目

3. 輸出：

測試計劃：
┌─────────────────────────────────────────────────────┐
│  📋 測試案例                                        │
│                                                     │
│  ✅ Happy Path:                                     │
│     • 計算多個項目的總和                            │
│     • 計算單一項目                                  │
│                                                     │
│  🔲 Edge Cases:                                     │
│     • 空陣列應返回 0                                │
│     • 含折扣的項目                                  │
│                                                     │
│  ❌ Error Cases:                                    │
│     • 負數價格應拋出錯誤                            │
│     • 無效項目格式                                  │
│                                                     │
│  覆蓋率目標：80% statements                         │
└─────────────────────────────────────────────────────┘

與其他 Skill 的協作

┌─────────────────────────────────────────────────────────────────┐
│  在 PDCA 循環中的位置                                           │
│                                                                 │
│  [實作功能] → [test-helper] → [執行測試] → [code-reviewer]     │
│                   ↓                            ↓                │
│            產出測試案例                    審查程式碼            │
│                                                                 │
│  測試失敗 → [debug-helper] → 修正 → 重新測試                   │
└─────────────────────────────────────────────────────────────────┘

設計原則

1. 測試優先思維 - 功能完成就該有測試
2. 全面覆蓋 - 正常、邊界、錯誤都要測
3. 可維護 - 測試程式碼也要好維護
4. 快速執行 - 單元測試要快
5. 獨立性 - 測試之間不互相依賴

限制與邊界

• 這是「設計測試」不是「自動生成完美測試」
• 複雜邏輯需要人工判斷測試策略
• 整合測試和 E2E 測試需要環境配置
• 測試品質依賴對需求的理解