title: "Testing Strategies for Architects: Testing Pyramid trong hệ thống phức tạp"
series: "Software Architecture Masterclass"
part: "Phần 4 — Bảo mật & Chất lượng"
order: 36
audience: "Solutions Architect & Technical Lead"
reading_time: "14 phút"
tags:

testing-strategy
testing-pyramid
contract-testing
microservices
quality-engineering
distributed-systems

Testing Strategies for Architects: Testing Pyramid trong hệ thống phức tạp

Một team mà tôi từng review có suite gồm 340 test end-to-end (E2E), chạy qua Cypress, mô phỏng toàn bộ hành trình người dùng từ đăng nhập tới thanh toán. Suite này chạy 47 phút trên CI, flaky khoảng 12% mỗi lần chạy — nghĩa là cứ 8 lần chạy thì có 1 lần fail vì lý do không liên quan đến code (timing, network, thứ tự test). Đội ngũ dành trung bình 6 giờ/tuần chỉ để re-run và debug test giả-fail. Không ai dám xoá test cũ vì "biết đâu nó đang bắt lỗi thật".

Một team khác, cùng công ty, cùng hệ thống microservices, đi theo hướng ngược lại: coverage unit test 92%, mock hoá mọi dependency ngoài, CI chạy 90 giây. Mọi PR đều xanh. Rồi một ngày, service Đơn hàng đổi format field total_amount từ số nguyên (cents) sang chuỗi thập phân, tất cả unit test của chính nó vẫn pass — vì mock trả về đúng cái nó tự định nghĩa. Service Thanh toán ở downstream nhận dữ liệu sai định dạng, tính sai tiền, chỉ phát hiện ra khi khách hàng report production.

Hai câu chuyện, hai thái cực, cùng một nguyên nhân gốc: không ai thiết kế chiến lược test theo tầng — mỗi tầng bắt một loại lỗi khác nhau, và không tầng nào thay thế được tầng khác.

The Problem

Trong một hệ thống đơn giản (một service, một database), câu hỏi "test thế nào" tương đối dễ trả lời — viết unit test cho logic nghiệp vụ, thêm vài integration test cho tầng DB, xong. Nhưng trong hệ thống phân tán — nhiều service giao tiếp qua HTTP/gRPC/message queue, mỗi service một team sở hữu, deploy độc lập — bài toán test bị nhân lên theo cấp số nhân của số lượng ranh giới (boundary) giữa các service.

Vấn đề kiến trúc cụ thể là: team luôn có xu hướng lệch về một trong hai cực, và cả hai cực đều để lọt lỗi mà lẽ ra phải bắt được trước production.

Cực thứ nhất — chỉ tin E2E test. Lý do tâm lý dễ hiểu: E2E test mô phỏng đúng hành vi người dùng thật, chạy qua đúng luồng thật, nên "an tâm" nhất. Nhưng E2E test chậm (phải dựng toàn bộ môi trường, mọi service phải chạy thật), dễ vỡ (flaky vì phụ thuộc network, timing, dữ liệu test dùng chung), và khi fail thì rất khó biết lỗi nằm ở service nào — phải debug qua nhiều lớp log của nhiều team khác nhau. Chi phí bảo trì tăng tuyến tính, đôi khi phi tuyến, theo số lượng luồng nghiệp vụ.

Cực thứ hai — chỉ tin unit test. Unit test nhanh, ổn định, dễ viết, dễ chạy trên máy dev. Nhưng unit test mock hoá mọi thứ bên ngoài ranh giới của chính nó — và mock chỉ đúng nếu giả định của người viết mock về hành vi bên ngoài là đúng. Khi service B đổi contract (request/response shape, status code, tên field, ý nghĩa của field), toàn bộ unit test của service A vẫn xanh, vì mock của A không hề biết B đã đổi. Đây chính là "lỗ hổng tích hợp" (integration gap) — loại lỗi mà unit test về bản chất không thể bắt được, dù coverage có đạt 100%.

Cả hai cực đều là hệ quả của việc thiếu một tầng ở giữa — tầng xác nhận rằng các ranh giới giữa các thành phần thực sự khớp nhau, mà không cần dựng toàn bộ hệ thống thật để kiểm tra.

The Theory

Testing Pyramid (kim tự tháp kiểm thử), khái niệm được Mike Cohn phổ biến, mô tả tỷ lệ đầu tư hợp lý giữa các tầng test theo hình kim tự tháp: đáy rộng (nhiều unit test), giữa hẹp hơn (integration test), đỉnh rất hẹp (E2E test). Logic đằng sau tỷ lệ này không phải là "unit test tốt hơn", mà là đánh đổi giữa tốc độ phản hồi (feedback speed) và phạm vi bao phủ thực tế (real-world coverage).

Unit test (đáy): kiểm tra một đơn vị logic (function, class, use-case) cô lập hoàn toàn khỏi dependency ngoài (DB, network, service khác) bằng mock/stub/fake. Chạy trong mili-giây, hàng nghìn test chạy trong vài giây. Bắt lỗi logic nghiệp vụ, edge-case tính toán, nhánh điều kiện.
Integration test (giữa): kiểm tra một thành phần phối hợp với dependency thật hoặc gần-thật (DB thật chạy trong container, cache thật, message broker thật). Chậm hơn unit test một bậc, nhưng bắt được lỗi ở tầng "code của tôi có nói đúng ngôn ngữ với hạ tầng không" — query SQL sai cú pháp, transaction không rollback đúng, serialize/deserialize sai.
E2E test (đỉnh): kiểm tra toàn bộ luồng nghiệp vụ đi qua nhiều service thật, mô phỏng hành vi người dùng cuối. Chậm nhất, dễ vỡ nhất, nhưng là bằng chứng gần nhất với "hệ thống hoạt động đúng trong thực tế".

Trong hệ thống phân tán/microservices, kim tự tháp cổ điển thiếu một tầng quan trọng: Contract Testing (kiểm thử hợp đồng). Đây là tầng chèn giữa integration test và E2E test, giải quyết đúng vấn đề mà cả hai cực ở trên đều bỏ sót: xác nhận rằng ranh giới giữa hai service — request format, response schema, status code, error contract — khớp với nhau, mà không cần dựng cả hai service thật chạy cùng lúc.

Cơ chế phổ biến nhất là consumer-driven contract testing (kiểu Pact): service tiêu thụ (consumer) định nghĩa kỳ vọng của nó về response từ service cung cấp (provider) thành một "hợp đồng" (file JSON mô tả request/response mẫu). Hợp đồng này được lưu lại (thường trong một Pact Broker hoặc registry tương đương). Phía provider, trong CI của chính nó, chạy lại các hợp đồng đó để xác nhận nó vẫn thoả mãn — nếu provider đổi contract mà chưa thông báo, CI của provider sẽ đỏ ngay tại thời điểm merge, không phải tại production. Điểm mấu chốt: cả hai phía đều test độc lập, không cần dựng môi trường tích hợp đầy đủ, nhưng vẫn bắt được đúng loại lỗi mà E2E test mới bắt được trước đây — chỉ nhanh hơn và ổn định hơn rất nhiều bậc.

The Trade-off

Đây là phần không thể mơ hồ — mỗi lựa chọn đầu tư đều có giá cụ thể.

Nếu đầu tư nặng vào E2E test (được gì, mất gì):

Được: độ tin cậy cao nhất về "hệ thống hoạt động đúng end-to-end" — đây là loại test duy nhất bắt được lỗi phát sinh từ tương tác thực sự giữa nhiều service, môi trường, cấu hình mạng, thứ tự message thực tế.
Mất: tốc độ CI giảm mạnh (từ giây sang phút, thậm chí hàng chục phút khi số luồng tăng); độ ổn định giảm — mỗi service tham gia luồng là một điểm có thể gây flaky (timeout, race condition, dữ liệu test đụng nhau); chi phí hạ tầng test tăng (phải dựng môi trường staging-like đầy đủ); và quan trọng nhất — khi test fail, thời gian debug tăng theo cấp số nhân vì lỗi có thể nằm ở bất kỳ đâu trong chuỗi service, đòi hỏi nhiều team cùng vào cuộc để xác định nguyên nhân.

Nếu đầu tư chỉ vào unit test (được gì, mất gì):

Được: tốc độ phản hồi cực nhanh (giây), chi phí bảo trì thấp, dễ chạy cục bộ, dễ viết theo TDD, phù hợp để bắt lỗi logic nghiệp vụ tinh vi (tính thuế, tính chiết khấu, state machine nội bộ).
Mất: hoàn toàn mù trước lỗi tích hợp — vì mock luôn "đúng" theo định nghĩa của người viết mock, không phản ánh được thay đổi thực tế ở phía cung cấp dependency. Coverage 100% không nói lên điều gì về việc hệ thống có hoạt động đúng khi ráp lại với nhau hay không. Loại lỗi này thường chỉ lộ ra ở staging muộn hoặc production — nơi chi phí sửa cao hơn nhiều so với chi phí bắt lỗi sớm ở CI.

Nếu thêm contract testing vào giữa (được gì, mất gì):

Được: bắt được phần lớn lỗi tích hợp ở ranh giới service mà không cần chi phí dựng toàn bộ môi trường — nhanh gần bằng unit test, nhưng bao phủ đúng loại rủi ro mà E2E mới bắt được trước đây. Cho phép hai team ở hai service phát triển độc lập, miễn là cả hai đều tuân thủ hợp đồng đã thoả thuận — giảm phụ thuộc lịch trình giữa các team.
Mất: cần kỷ luật quy trình — phải có nơi lưu trữ hợp đồng dùng chung (broker), phải có bước CI ở cả hai phía consumer và provider, và hợp đồng chỉ có giá trị nếu được cập nhật đồng bộ với thay đổi thực tế — một hợp đồng lỗi thời (viết một lần rồi bỏ quên) tạo ra cảm giác an toàn giả (false confidence), nguy hiểm hơn cả việc không có contract test, vì team tin tưởng vào một tấm lưới đã rách. Ngoài ra, contract test không thay thế được E2E cho các luồng có yêu cầu về thứ tự sự kiện, race condition thực tế, hoặc hành vi side-effect qua nhiều bước (ví dụ luồng SAGA nhiều bước bù trừ) — vẫn cần một số lượng nhỏ E2E test cho các luồng nghiệp vụ cốt lõi nhất.

Kết luận đánh đổi: không có tầng nào "tốt hơn" — mỗi tầng trả lời một câu hỏi khác nhau (unit: "logic của tôi đúng chưa?", contract: "ranh giới giữa tôi và người khác có khớp không?", E2E: "cả chuỗi có chạy đúng trong điều kiện gần thật không?"). Đầu tư lệch về bất kỳ tầng nào cũng đồng nghĩa với việc chấp nhận mù trước loại rủi ro mà tầng đó phụ trách.

The Architecture Diagram

graph TD
    subgraph pyramid [" "]
        direction TB
        E2E["E2E Test<br/>(rất ít — luồng nghiệp vụ cốt lõi)<br/>Chậm · Dễ vỡ · Tin cậy cao nhất"]
        CONTRACT["Contract Test<br/>(vừa phải — mọi ranh giới service)<br/>Nhanh · Ổn định · Bắt lỗi tích hợp"]
        INTEGRATION["Integration Test<br/>(ít hơn unit — DB/cache/queue thật)<br/>Trung bình · Bắt lỗi hạ tầng"]
        UNIT["Unit Test<br/>(nhiều nhất — logic nghiệp vụ cô lập)<br/>Rất nhanh · Rất ổn định"]
    end

    E2E --> CONTRACT --> INTEGRATION --> UNIT

    style E2E fill:#7f1d1d,color:#fff
    style CONTRACT fill:#78350f,color:#fff
    style INTEGRATION fill:#164e63,color:#fff
    style UNIT fill:#14532d,color:#fff

sequenceDiagram
    participant Dev as Team Service A (Consumer)
    participant Broker as Contract Broker
    participant CI_A as CI của Service A
    participant CI_B as CI của Service B (Provider)

    Dev->>Dev: Viết consumer test, định nghĩa kỳ vọng response từ B
    Dev->>Broker: Publish hợp đồng (contract) lên Broker
    CI_A->>Broker: Chạy consumer test, xác nhận hợp đồng hợp lệ
    Note over CI_B: Khi Service B chuẩn bị deploy
    CI_B->>Broker: Lấy tất cả hợp đồng mà B là provider
    CI_B->>CI_B: Chạy provider verification với hợp đồng đó
    alt Hợp đồng bị vi phạm
        CI_B-->>Dev: Build FAIL — chặn deploy trước khi ảnh hưởng Service A
    else Hợp đồng thoả mãn
        CI_B-->>Broker: Verification pass — an toàn để deploy
    end

Implementation Guardrails

Mọi ranh giới service (API contract, event schema, message payload) bắt buộc phải có contract test — không được phép chỉ dựa vào E2E test để bắt lỗi tích hợp. Nếu service A gọi service B qua REST/gRPC hoặc publish/consume event qua message queue, phải tồn tại một bài test xác nhận contract độc lập với việc dựng cả hai service thật chạy cùng lúc.
Hợp đồng (contract) phải được version hoá và lưu ở nơi cả hai team truy cập được (broker dùng chung), không phải file nằm rải rác trong repo của từng team. Provider bắt buộc chạy verification trong CI của chính nó trước khi merge/deploy — không có ngoại lệ "để sau".
Giới hạn cứng số lượng E2E test theo số luồng nghiệp vụ cốt lõi (critical user journey), không theo số lượng tính năng. Một quy tắc thực dụng: nếu một luồng không trực tiếp ảnh hưởng doanh thu hoặc an toàn dữ liệu, nó không xứng đáng có E2E test riêng — hãy đẩy xuống integration/contract test.
Mọi test flaky (fail không nhất quán) phải được quarantine hoặc xoá trong vòng một sprint, không được để chạy tiếp "cho yên tâm". Test flaky không tạo ra tín hiệu — nó tạo ra tiếng ồn, và tiếng ồn khiến team bỏ qua cả tín hiệu thật khi nó xuất hiện.

Architect's Verdict

Trong hệ phân tán, contract testing giữa các service quan trọng ngang unit test trong một service — và đây chính xác là chỗ phần lớn team đầu tư thiếu nhất, vì nó đòi hỏi phối hợp giữa hai team thay vì một người tự viết test trong repo của mình. Nếu bạn chỉ có ngân sách để cải thiện một tầng test trong quý này, đừng thêm E2E test — hãy thêm contract test ở những ranh giới service có tần suất thay đổi cao nhất và chi phí lỗi tích hợp cao nhất (thanh toán, đơn hàng, xác thực). Đó là nơi một đô-la đầu tư vào test mang lại nhiều điểm tin cậy nhất trên mỗi giây CI.

🔗 Bài viết liên quan

Bài trước: Cost Optimization · Bài tiếp theo: Technical Debt Management