Introduction to Unit Test

Vào năm 2015 có một sự kiện làm thay đổi suy nghĩ của mình về Testing trong quy trình phát triển phần mềm. Đây là lần đầu tiên mình phải viết report 5 whys 9 steps. Nguyên nhân chính của vấn đề này là mình xem nhẹ Unit Test và hậu quả thì khá nặng nề. Vì sao thì các bạn xem tiếp bài viết nhé ;)).

Trước đó, lúc học đại học thì mình đã biết khái niệm Black Box Test và White Box Test. Khái niệm Unit Test lần đầu mình được biết vào năm 2013 khi mình còn ở Global CyberSoft. Lúc này leader cũng chỉ xem nó mang tính “report”, các “chốt chặn” chất lượng cho dự án hầu hết ở bước Code Review và Test. May mắn thay leader và QC team mình chuyên môn rất tốt nên chất lượng dự án vẫn ở mức tốt.

Vào năm 2015 mình chuyển qua làm việc tại Mulodo. Mình và một em sinh năm 91 tiếp nhận 2 dự án của 2 bạn chuẩn bị rời công ty. Thời gian gấp rút nhưng tài liệu thiếu, tinh thần muốn rời đi làm cho quá trình transfer dự án không được tốt. Kết quả bọn mình đã phải nhận một “bug siêu khủng long” ngay lần change request thứ 2. Nguyên nhân là do sửa lại một hàm utility và vì hàm này được sử dụng ở rất nhiều function nên lỗi này rất nghiêm trọng. Lúc này mình vẫn nghĩ nguyên nhân lỗi là do “miss knowlead” hoàn toàn có thể phát hiện ở bước Code Review. Nhưng sau khi trúng “thông não chi thuật” của Manager thì mình nhận ra lỗi này hoàn toàn có thể tránh được nếu áp dụng Unit Test đúng.

Vậy Unit Test là gì và vì sao nó lại cần thiết?

What is Unit Test?

Unit Test là một bước trong quy trình phát triển phần mềm. Nó được nên được bắt đầu ngay sau Functional Design, trước Implement và kết thúc sau khi Implement xong. Nhằm mục đích đảm bảo phần code được implement đúng với thiết kế. Unit Test được thực hiện bởi lập trình viên và được xem là White Box Test.

Unit ở đây đối với lập trình hướng đối tượng là method, đối với lập trình hàm là function, đối với lập trình thủ tục là procedure. Khi này lập trình viên sẽ liệt kê ra tất cả các trường hợp logic mà Unit đó sẽ chạy qua, từ đó sẽ tạo ra một bộ các input và output (bao gồm cả kết quả mong muốn và lỗi mong muốn) tương ứng cho các trường hợp đó. Framework Unit Test sẽ hỗ trợ xác nhận lại input và output cho từng trường hợp và báo cáo kết quả cuối cùng.

Why do I have to write Unit Test?

• Đảm bảo Unit chạy đúng với thiết kế. Sự đảm bảo này lại càng quan trọng trong trường hợp update lại logic của Unit. Giá như mình biết cái này sớm hơn và “người trước” viết Unit Test nghiêm chỉnh hơn thì đã không dính lỗi ở ở trên :((.
• Hiễu rõ hơn về yêu cầu và định hướng Implement trước. Như mình đã nói, Unit Test phải bắt đầu trước Implement, khi này ta sẽ liệt kê ra tất cả các trường hợp sẽ xảy ra và chốt được bộ input và output cho các trường hợp đó, giống như việc muốn đi đâu thì cần biết điểm đến vậy đó ;)).
• Phát hiện lỗi sớm → tiết kiệm chi phí và thời gian.
• Khi viết Unit Test developer cần phải xem lại code của chính mình. Đây cũng có thể xem là một hình thức “ép buộc” tự review ;)).
• Giảm tải cho Code Review. Đối với ai đang là lead hoặc phải peer review thì chắc chắn muốn người implement code thực hiện Unit Test.
• Phát hiện những lỗi tiềm ẩn mà Black Box Test không thể phát hiện.
• Là một phần không thể thiếu trong việc triển khai CI/CD.

Concepts in Unit Test?

• Test Case: là một trường hợp logic mà Unit cần test có thể xảy ra trong quá trình chạy. Với mỗi Test Case ta cần phải xác định được một bộ input và output tương ứng.
• Assertion: Là một phát biểu mô tả các công việc kiểm tra output cần tiến hành. Như trong JUnit là các hàm: assertEquals, assertThrows, assertArrayEquals, assertNotNull, assertNull…
• Test Suite: là tập hợp các Test Case. Các Test Suite có thể phân loại dựa vào module, package, class hoặc thậm chí là Unit tùy thuộc vào số lượng Test Case, độ phức tạp của Unit hoặc chiến lược của người viết Unit Test.
• Production Code: Là phần code chính sẽ được chạy khi deploy lên production.
• Test Code: Là phần code để thực thi Unit Test, nó bao gồm tất cả các Test Suite. Phần code này sẽ được chạy trong quá trình build và không include vào Production Code. Ngoài ra lập trình viên cũng nên chạy ở local trước khi Merge (Pull) Request.

Kết: Mong sau bài viết này bạn sẽ thấy được sự quan trọng của Unit Test. Kiến thức về Unit Test thì rất nhiều và mình sẽ tiếp tục viết nhiều nâng cao hơn về chủ đề thú vị này. Kết thúc bài viết mình xin trích một câu nói từ Manager cũ của mình người đã giúp mình “thông não” ;)).

Unit Test không phải là trách nhiệm của lập trình viên mà là quyền lợi. Nó bảo vệ chúng ta khỏi những lỗi tiềm ẩn. Vì thế hãy viết nó “bằng cả trái tim”.
— Tài Nguyễn

Cảm ơn các bạn đã đọc tới đây.