Kiểm thử trước khi PR - Phần 1 - Unit Test và Integration Test khác nhau ở đâu?

Nhiều bạn dev vẫn hay nghĩ kiểm thử là cái "chạy thử lần cuối" trước khi merge code cho xong. Nhưng thật ra kiểm thử nên là một phần của việc làm ra code chất lượng, chứ không phải bước kiểm tra qua loa ở cuối. Và nó không nên phụ thuộc vào việc "hôm nay bạn có cẩn thận không" — mà nên là thói quen chung của cả team. Đây là bài đầu trong series 3 bài mình viết lại từ buổi training nội bộ về kiểm thử. Bài này nói về hai khái niệm nền: mô hình chữ V, và sự khác nhau giữa Unit Test với Integration Test.

Mô hình chữ V là gì?

Nói đơn giản, mô hình chữ V cho thấy mỗi bước thiết kế đều có một bước kiểm thử "soi lại" tương ứng:

Trong 4 bước kiểm thử đó, Unit Test và Integration Test là hai phần mà team dev mình chịu trách nhiệm chính — nói cách khác, đây là "tuyến đầu" xây dựng chất lượng, trước khi sản phẩm đi tới các vòng kiểm thử ở tầm hệ thống hay nghiệp vụ.

Vậy Unit Test và Integration Test khác nhau ở đâu?

Nếu phải gói lại trong một câu: khác nhau ở mức độ liên kết thực tế khi xác nhận.

Tóm lại một câu cho dễ nhớ: Unit Test giữ cho từng thành phần chạy đúng, Integration Test giữ cho cả luồng đi thông suốt.

Unit Test thì cần soi cái gì?

Unit Test là kiểm tra một xử lý đơn lẻ — một hàm, một phương thức, một class — có làm đúng như thiết kế không. Cụ thể là 5 khía cạnh sau:

1. Trả về kết quả chính xác đối với giá trị đầu vào
2. Các nhánh điều kiện hoạt động chính xác
3. Xác thực dữ liệu (validation) đúng như đặc tả
4. Xử lý lỗi chính xác khi có giá trị ngoài dự kiến
5. Định dạng dữ liệu trước khi lưu CSDL chính xác

Chỉ test luồng "mọi thứ đều ổn" (happy path) thì chưa đủ đâu — chỗ hay ra lỗi thường nằm ở các ranh giới:

• Luồng chuẩn: đầu vào giả định cho kết quả đầu ra như kỳ vọng
• Bất thường: giá trị sai hoặc để trống sẽ báo lỗi phù hợp
• Giá trị biên: kiểm tra kỹ ranh giới của giới hạn trên và dưới. Ví dụ kinh điển: giới hạn 255 ký tự → 255 ký tự là OK, 256 ký tự là NG.
• Rẽ nhánh: đảm bảo mọi nhánh điều kiện hoạt động chính xác
• Ngoại lệ: xử lý an toàn và phù hợp khi xảy ra lỗi hệ thống

Còn Integration Test thì soi cái gì?

Integration Test không chỉ là kiểm tra "kết nối được hay không" — mà còn phải để tâm tới cả trường hợp thất bại, phân quyền, và dữ liệu có nhất quán không, dọc theo luồng: Màn hình (UI) → API → DB → Email/Dịch vụ bên ngoài. 5 khía cạnh nên xác nhận:

1. Giá trị chính xác có được gửi từ màn hình đến API hay không
2. Kết quả xử lý của API có được lưu chính xác vào DB hay không
3. Có chuyển hướng đến đúng màn hình sau khi đăng ký hay không
4. Hiển thị và thao tác có được kiểm soát theo quyền hay không
5. Có thể xử lý thành công hoặc thất bại khi liên kết ngoài hay không (Mail, HubSpot, Slack, S3...)

Biết phân biệt hai loại này rồi thì câu hỏi tiếp theo là: viết test case sao cho không sót ý? Phần 2 mình sẽ nói về cách phân tích "Đầu vào - Xử lý - Đầu ra", viết test case theo Given-When-Then, kèm ví dụ thực tế với tính năng đăng ký thành viên.