Unit test là gì? Kinh nghiệm làm Unit test

Sep 29, 2020

Unit Test là gì?

Một Unit là một thành phần PM nhỏ nhất mà ta có thể kiểm tra được như các hàm (Function), thủ tục (Procedure), lớp (Class), hoặc các phương thức (Method).

Vì Unit được chọn để kiểm tra thường có kích thước nhỏ và chức năng hoạt động đơn giản, chúng ta không khó khăn gì trong việc tổ chức, kiểm tra, ghi nhận và phân tích kết quả kiểm tra nên việc phát hiện lỗi sẽ dễ dàng xác định nguyên nhân và khắc phục cũng tương đối dễ dàng vì chỉ khoanh vùng trong một Unit đang kiểm tra.

Mỗi UT sẽ gửi đi một thông điệp và kiểm tra câu trả lời nhận được đúng hay không, bao gồm:

Các kết quả trả về mong muốn
Các lỗi ngoại lệ mong muốn

Các đoạn mã UT hoạt động liên tục hoặc định kỳ để thăm dò và phát hiện các lỗi kỹ thuật trong suốt quá trình phát triển, do đó UT còn được gọi là kỹ thuật kiểm nghiệm tự động. UT có các đặc điểm sau:

Đóng vai trò như những người sử dụng đầu tiên của hệ thống.
Chỉ có giá trị khi chúng có thể phát hiện các vấn đề tiềm ẩn hoặc lỗi kỹ thuật.

Thiết kế Unit test

Mỗi UT đều được tiết kế theo trình tự sau:

Thiết lập các điều kiện cần thiết: khởi tạo các đối tượng, xác định tài nguyên cần thiết, xây dựng các dữ liệu giả…

Triệu gọi các phương thức cần kiểm tra.
Kiểm tra sự hoạt động đúng đắn của các phương thức.
Dọn dẹp tài nguyên sau khi kết thúc kiểm tra.

Lợi ích của Unit test

Thời gian đầu, người ta thường do dự khi phải viết UT thay vì tập trung vào code cho các chức năng nghiệp vụ. Công việc viết Unit Test có thể mất nhiều thời gian hơn code rất nhiều nhưng lại có lợi ích sau:

Tạo ra môi trường lý tưởng để kiểm tra bất kỳ đoạn code nào, có khả năng thăm dò và phát hiện lỗi chính xác, duy trì sự ổn định của toàn bộ PM và giúp tiết kiệm thời gian so với công việc gỡ rối truyền thống.
Phát hiện các thuật toán thực thi không hiệu quả, các thủ tục chạy vượt quá giới hạn thời gian.
Phát hiện các vấn đề về thiết kế, xử lý hệ thống, thậm chí các mô hình thiết kế.
Phát hiện các lỗi nghiêm trọng có thể xảy ra trong những tình huống rất hẹp.
Tạo hàng rào an toàn cho các khối mã: Bất kỳ sự thay đổi nào cũng có thể tác động đến hàng rào này và thông báo những nguy hiểm tiềm tàng.

Trong môi trường làm việc Unit Test còn có tác dụng rất lớn đến năng suất làm việc:

Giải phóng chuyên viên QA khỏi các công việc kiểm tra phức tạp.
Tăng sự tự tin khi hoàn thành một công việc. Chúng ta thường có cảm giác không chắc chắn về các đoạn mã của mình như liệu các lỗi có quay lại không, hoạt động của module hiện hành có bị tác động không, hoặc liệu công việc hiệu chỉnh mã có gây hư hỏng đâu đó…
Là công cụ đánh giá năng lực của bạn. Số lượng các tình huống kiểm tra (test case) chuyển trạng thái “pass” sẽ thể hiện tốc độ làm việc, năng suất của bạn.

Những ngộ nhận về Unit test

Intergration test (test tích hợp) sẽ tìm thấy tất cả lỗi bằng mọi cách: Đây là một trong những quan niệm sai lầm thường gặp. Độ khó của các vấn đề sẽ tăng trong quy trình kiểm thử phần mềm. Càng ở những giai đoạn kiểm thử sau thì lỗi càng phức tạp, khó tìm và giải quyết hơn.
Nhiều lập trình viên cho rằng không bắt buộc phải có Unit test. Nhiều người tin tưởng rằng khả năng lập trình của họ đã tốt và phần mềm của họ không cần thiết phải có Unit test. Nhưng trong thế giới thực tế này, tất cả mọi người đều có thể gây ra lỗi và các hệ thống phần mềm thực tế còn phức tạp hơn rất nhiều.
Viết Unit test mất quá nhiều thời gian: Lập trình viên thường cho rằng unit test với họ là vô nghĩa bởi lẽ họ nghĩ rằng mã nguồn sẽ luôn luôn được kiểm thử bởi kiểm thử viên. Tuy nhiên, nếu không thực hiện Unit test, số lỗi được tìm thấy ở các giai đoạn sau càng nhiều và càng ở giai đoạn sau thì lỗi càng phức tạp, tốn rất nhiều thời gian và chi phí để sửa chữa.

Một số lưu ý khi viết Unit test

Chắc chắn rằng mỗi test case kiểm thử mức đơn vị sẽ độc lập với những test case khác. Không nên gọi một test case khác trong một test case. Test case không nên phụ thuộc vào nhau cả về data và thứ tự thực hiện.
Luôn luôn kiểm tra từng mô-đun một cách độc lập. Nếu không, sẽ có nhiều sự chồng chéo giữa các ca thử nghiệm và việc thay đổi đối với một đơn vị có thể ảnh hưởng đến tất cả các mô-đun khác và khiến phần mềm bị lỗi.
Đặt tên các đơn vị kiểm thử một cách rõ ràng và nhất quán. Đảm bảo rằng các test case dễ đọc, bất kỳ ai cũng có thể chọn test case và chạy nó mà không gặp bất kỳ vấn đề nào.
Khi triển khai việc thay đổi giao diện hoặc chức năng, cần chạy lại các test case trước đó nhằm đảm bảo việc thay đổi này không làm ảnh hưởng đến những test case cũ đã pass.
Luôn đảm bảo lỗi được xác định trong quá trình Unit test được sửa trước khi chuyển sang giai đoạn tiếp theo.
Không cố gắng viết test case để kiểm thử tất cả mọi thứ, thay vào đó nên tập chung vào kiểm thử sự ảnh hưởng của hành vi hệ thống.
Bên cạnh viết test case để test hành vi hệ thống, cần viết thêm test case để kiểm thử hiệu năng của mã nguồn.
Các testsuit nên đặt riêng ra, độc lập code với module
Không nên có nhiều assert trong một test case vì khi một điều kiện không thỏa mãn thì các assert khác sẽ bị bỏ qua.
Sau một thời gian dài, số lượng test case nhiều, thời gian chạy lớn. Nên chia ra nhóm test case cũ và test case mới, test case cũ sẽ chạy với tần xuất ít hơn.

Sưu tầm!

You need to login in order to like this post: click here