敏捷建構核心：透過測試分類實現極速建構 — 單元、組件、系統測試三層策略

前言：測試套件膨脹帶來的建構危機

某創業公司 2002 年起全面採用 JUnit + Ant + CruiseControl 持續整合。初期測試秒級完成，隨著代碼庫增長，測試數達 2000 支，完整建構耗時超過 3 小時。團隊被迫將測試移至夜間跑批，導致回饋延遲、錯誤堆積、開發者對測試失去信心。本文揭示測試分類分層策略，將單次建構時間從數小時壓縮至分鐘級，恢復敏捷回饋迴路。

一、核心洞見：「單元測試」不是單一概念

「我們寫單元測試」這句話極其模糊，如同「我家有動物」不知是貓還是熊。依執行時間、依賴範圍、撰寫成本將測試劃分為三個截然不同的層次：

二、三類測試深度定義與實作範例

1. 單元測試 — 速度與隔離的極致

定義：驗證單一類別/函數的邏輯，完全隔離外部依賴 (資料庫、檔案、網路、時間、隨機數)。

• 無 new File(), DriverManager.getConnection(), HttpClient
• 依賴以介面注入，測試時提供 Mock/Stub/Fake (Mockito, EasyMock, 手寫 Fake)
• 可在 TDD 紅-綠-重構 循環中毫秒級執行

// 純單元測試範例：計算折扣邏輯
@Test
public void testVolumeDiscount() {
    PricingEngine engine = new PricingEngine();
    // 無任何外部依賴，純記憶體運算
    assertEquals(90.0, engine.calculatePrice(100, 10), 0.001); // 10% off
    assertEquals(80.0, engine.calculatePrice(100, 25), 0.001); // 20% off
}

// 使用 Mock 隔離 Repository
@ExtendWith(MockitoExtension.class)
class OrderServiceTest {
    @Mock OrderRepository repo;
    @InjectMocks OrderService service;
    
    @Test
    void testPlaceOrder() {
        when(repo.save(any())).thenAnswer(inv -> inv.getArgument(0));
        Order order = service.placeOrder(new OrderRequest("user1", List.of(item)));
        assertNotNull(order.getId());
        verify(repo).save(order);
    }
}

2. 組件測試 — 真實依賴的受控驗證

定義：驗證多個類別協作或單一組件與基礎設施整合 (資料庫、檔案系統、訊息佇列)。使用嵌入式/輕量級實現替代生產環境。

• 資料庫：H2, Testcontainers (真實 PostgreSQL/MySQL 容器)
• 檔案系統：臨時目錄 (@TempDir)
• HTTP 服務：WireMock, MockWebServer
• 不啟動完整應用伺服器

// Spring Boot 整合測試 = 組件測試典型形式
@DataJpaTest // 自動配置 H2 + 測試事務回滾
@AutoConfigureTestDatabase(replace = Replace.NONE) // 用真實 Testcontainers DB
class OrderRepositoryTest {
    @Autowired OrderRepository repo;
    
    @Test
    void testFindByUserId() {
        User user = userRepository.save(new User("john"));
        Order order = repo.save(new Order(user, BigDecimal.TEN));
        
        List found = repo.findByUserId(user.getId());
        assertEquals(1, found.size());
        assertEquals(BigDecimal.TEN, found.get(0).getAmount());
    }
}

// 檔案處理組件測試
@TempDir Path tempDir;
@Test
void testCsvExport() throws IOException {
    File exportFile = tempDir.resolve("orders.csv").toFile();
    new CsvExporter(exportFile).export(orders);
    assertTrue(Files.size(exportFile.toPath()) > 0);
}

3. 系統測試 — 端到端真實環境驗證

定義：在完整部署拓撲中驗證跨系統業務流程 (UI、API、批次、排程)。

• Selenium / Cypress / Playwright (UI)
• RestAssured / Postman (API)
• 測試環境 = 生產環境縮小版 (同樣中介軟體、資料庫、外部服務)
• 資料準備複雜，執行緩慢，易斷裂

// API 系統測試範例
@Tag("system")
class OrderApiSystemTest {
    static final String BASE_URL = "https://test-env.company.com/api";
    
    @Test
    void testFullOrderFlow() {
        // 1. 建立訂單
        String orderId = given()
            .baseUri(BASE_URL)
            .body(new OrderRequest("user1", List.of(item)))
            .post("/orders")
            .then().statusCode(201)
            .extract().jsonPath().getString("id");
        
        // 2. 支付 (呼叫外部支付網關沙箱)
        given().baseUri(BASE_URL)
            .body(new PaymentRequest(orderId, "credit_card"))
            .post("/payments")
            .then().statusCode(200);
        
        // 3. 驗證狀態變更
        given().baseUri(BASE_URL)
            .get("/orders/" + orderId)
            .then().statusCode(200)
            .body("status", equalTo("PAID"));
    }
}

三、建構管線自動化分層執行策略

Maven/Gradle 設定範例

    maven-surefire-plugin 
    
        
            **/*UnitTest.java
            **/*Test.java 
        
        
            **/*ComponentTest.java
            **/*SystemTest.java
        
    


    maven-failsafe-plugin 
    
        
            integration-testverify
        
    
    
        
            **/*ComponentTest.java
            **/*SystemTest.java
        
    

CI/CD Pipeline 階段設計

stages:
  - name: fast-feedback          # < 5 分鐘
    script: mvn test             # 僅單元測試
    trigger: on every push
    
  - name: component-verification # < 15 分鐘
    script: mvn verify -DskipUnitTests=true
    trigger: on merge to main / PR
    
  - name: system-validation      # 30-60 分鐘
    script: mvn verify -Dtest=*SystemTest
    trigger: nightly / on release tag
    
  - name: performance-smoke      # 額外階段
    script: k6 run smoke.js
    trigger: on release tag

四、分類實施的關鍵技術手段

五、效益量化：從 3 小時到 3 分鐘

某專案實施分層前後對比：

六、避坑指南與最佳實務

• 不要混雜層次：單元測試中若出現 @Autowired、DataSource、Testcontainers 即為分類失敗
• 組件測試用 Testcontainers：避免 H2 與生產資料庫行為差異 (語法、鎖、索引)
• 系統測試隔離資料：每支測試自建自清資料，或使用資料庫快照/遷移腳本重置
• 測試金字塔不倒置：單元測試數量 ≫ 組件測試 ≫ 系統測試
• 冪等性：系統測試需可重複執行不產生副作用
• 平行化：單元/組件測試並行執行 (Maven -T 4, Gradle --parallel)，系統測試謹慎並行

總結

測試分類不是學術細分，而是工程效能的生存技能。將測試劃分為單元 (毫秒、隔離、高頻)、組件 (秒級、真實基礎設施、中頻)、系統 (分鐘級、完整環境、低頻) 三層，配合建構工具與 CI/CD 管線分階段執行，能將「三小時建構」壓縮為「三分鐘快速回饋」，讓測試真正成為敏捷開發的加速器而非煞車塊。