Wavi Books · Kỹ nghệ phần mềm & Clean Code

Unit Test là gì? Cách viết kiểm thử hữu ích cho developer

Nguyễn Minh Trí · Biên tập chuyên môn Wavi Books

Unit Test là gì, test case, mock, coverage và nguyên tắc viết kiểm thử nhanh, ổn định, giúp developer refactor an toàn.

## Unit Test là gì

## Điều đáng nhớ trước khi áp dụng nguyên tắc

Unit Test là gì, test case, mock, coverage và nguyên tắc viết kiểm thử nhanh, ổn định, giúp developer refactor an toàn. Mục tiêu không phải làm code trông đẹp hơn, mà là giúp con người hiểu và thay đổi phần mềm an toàn hơn.

Một đoạn code không có bug vẫn có thể khiến cả đội sợ thay đổi. Tên biến mơ hồ, hàm quá dài và test thiếu khiến mỗi lần sửa giống như dò mìn. Khi đó, chất lượng code không còn là chuyện thẩm mỹ; nó trở thành thời gian, rủi ro và chi phí thật của dự án.

Unit test tốt không chỉ báo code đúng hôm nay. Nó cho bạn đủ tự tin để sửa code vào tháng sau mà không phải nín thở chờ hệ thống gặp lỗi.

Unit test kiểm tra một đơn vị hành vi nhỏ trong điều kiện được kiểm soát. Test tốt chạy nhanh, có kết quả ổn định và mô tả hành vi quan trọng thay vì bám chặt chi tiết cài đặt.

Mock hữu ích để cô lập hệ thống ngoài, nhưng lạm dụng mock khiến test vẫn xanh dù các thành phần thật không tích hợp được. Cần cân bằng unit, integration và end-to-end test.

## Những khái niệm cốt lõi cần nắm

## Kiểm thử nên bảo vệ hành vi, không trói cách cài đặt

Một unit test tập trung vào đơn vị hành vi nhỏ, chạy nhanh và cho biết rõ điều gì sai. Test càng phụ thuộc vào chi tiết bên trong, càng dễ vỡ khi refactor dù sản phẩm vẫn hoạt động đúng.

## Chuyện gì xảy ra khi đem vào dự án thật?

Đội ngũ có thể sở hữu hàng nghìn test nhưng vẫn sợ deploy nếu test chỉ kiểm tra getter, mock mọi thứ hoặc bỏ qua các luồng nghiệp vụ quan trọng.

## Nếu bắt đầu hôm nay, tôi sẽ làm thế này

Bắt đầu từ quy tắc có rủi ro cao và các trường hợp biên. Đặt tên test như một câu mô tả hành vi; khi test thất bại, tên đó nên giúp bạn hiểu chuyện gì vừa xảy ra.

- Arrange thiết lập dữ liệu và phụ thuộc.

- Act thực hiện hành vi.

- Assert kiểm tra kết quả có ý nghĩa.

- Test double thay thế phụ thuộc khi cần.

## Lộ trình thực hành từng bước

- Bước 1: Bắt đầu từ logic nghiệp vụ dễ kiểm chứng.

- Bước 2: Đặt tên test theo tình huống và kết quả.

- Bước 3: Chạy trong CI và sửa test flaky ngay.

## Những sai lầm thường gặp

- Chỉ kiểm tra getter và setter.

- Phụ thuộc thời gian hoặc mạng thật.

- Theo đuổi 100% coverage mà bỏ sót kịch bản quan trọng.

## Góc nhìn dành cho người học và developer Việt Nam

Đội phát triển tại Việt Nam nên xem test như tài liệu hành vi sống và tiêu chuẩn review, đặc biệt ở module thanh toán, đơn hàng và phân quyền.

## Nên học tiếp như thế nào?

## Bài tập viết test bảo vệ điều quan trọng

Chọn một hàm tính phí, giảm giá hoặc phân quyền có quy tắc rõ. Viết test cho trường hợp bình thường, biên và dữ liệu không hợp lệ; đặt tên mỗi test như một câu mô tả hành vi. Sau đó cố tình tạo lỗi để xem thông báo có giúp bạn xác định nguyên nhân nhanh không. Một test hữu ích phải làm thất bại trở nên dễ hiểu, không chỉ làm con số coverage tăng lên.

## Ví dụ xuyên suốt để nối kiến thức

Hàm tính phí vận chuyển có miễn phí theo giá trị đơn, phụ phí vùng xa và giới hạn cân nặng. Đây là nơi test tạo giá trị vì quy tắc có nhiều biên. Test getter đơn giản thì dễ viết nhưng ít giúp team tự tin khi nghiệp vụ thay đổi.

## Khung triển khai từ thử nghiệm đến thực tế

Ưu tiên test cho quy tắc quan trọng, nhánh có rủi ro và lỗi từng xảy ra. Test nên mô tả hành vi quan sát được thay vì gọi từng method nội bộ chỉ để đạt coverage.

### Bốn bước nên đi theo thứ tự

- Liệt kê ví dụ nghiệp vụ trước khi viết implementation.

- Viết test tên rõ, dữ liệu tối thiểu và một lý do thất bại.

- Tách dependency chậm hoặc không ổn định ở đúng ranh giới.

- Chạy test trong CI và sửa test flaky như sửa lỗi sản phẩm.

## Trade-off cần nhìn thẳng

Mock giúp cô lập nhưng mock quá sâu khiến test chỉ xác nhận cách code đang viết. Test tích hợp chậm hơn nhưng cần thiết ở ranh giới database, network và serialization.

## Đánh giá bằng kết quả thay vì cảm giác

Theo dõi thời gian chạy, tỷ lệ flaky, lỗi hồi quy lọt qua và thời gian chẩn đoán khi test đỏ. Coverage chỉ là bản đồ vùng chưa đi qua, không phải giấy chứng nhận chất lượng.

## Giá trị đối với năng lực nghề nghiệp

Developer viết test tốt có thể thay đổi hệ thống nhanh hơn vì rủi ro được nhìn thấy sớm. Đây là lợi thế nghề nghiệp thực tế, không chỉ là yêu cầu quy trình.

## Câu hỏi tự kiểm tra trước khi chuyển chủ đề

Bạn có thể giải thích Unit Test là gì bằng ngôn ngữ của mình, nêu một trường hợp nên dùng, một trường hợp không nên dùng và chỉ ra cách đo kết quả hay chưa? Nếu chưa, hãy quay lại ví dụ nhỏ trong bài, thay đổi một ràng buộc rồi quan sát điều gì buộc giải pháp phải thay đổi. Đây là cách biến kiến thức đọc được thành khả năng ra quyết định.

## Góc nhìn dành cho developer Việt Nam

Với developer đang làm việc trong các đội sản phẩm tại Việt Nam, hãy dùng nguyên tắc như câu hỏi để review chứ đừng biến chúng thành luật cứng. Mục tiêu là giúp đồng đội đọc nhanh hơn, sửa an toàn hơn và trao đổi chính xác hơn về ý định của code.

## Đọc tiếp trên Wavi Books

Nếu bạn muốn học chủ đề này theo một lộ trình có cấu trúc, có thể xem Clean Code, 2nd Edition bản tiếng Việt tại [Wavi Books](/sach/clean-code-robert-c-martin-2026). Sách liên quan được đặt sau phần kiến thức để bạn có thể đánh giá nội dung trước khi chọn mua.