Unit test, chuyện chẳng của riêng devs nào!
September 28, 2020Câu chuyện về unit test cho mỗi dev thì chẳng phải của riêng ai, nhất là khi bạn còn phải cover cả unit test cho những function của những người đồng đội của mình.
Nếu ai đó chưa biết về unit test thì mình có thể định nghĩa nhanh và đơn giản như sau:
Trong kiểm thử phần mềm có 4 mức độ kiểm thử: Unit test ( kiểm thử mức đơn vị), Intergration test ( kiểm thử tích hợp), System test (kiểm thử hệ thống), Acceptance test (kiểm thử chấp nhận).
Unit Test là gì?
Unit Test là một loại kiểm thử phần mềm trong đó các đơn vị hay thành phần riêng lẻ của phần mềm được kiểm thử. Kiểm thử đơn vị được thực hiện trong quá trình phát triển ứng dụng. Mục tiêu của Kiểm thử đơn vị là cô lập một phần code và xác minh tính chính xác của đơn vị đó.
Unit 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).
Lợi ích của Unit test
- Viết Unit test tốt giúp tăng sự tin tưởng vào mã nguồn được thay đổi hoặc bảo trì. Bởi lẽ, nếu viết Unit test tốt, mỗi lần có sự thay đổi bên trong mã nguồn và chạy unit test, chúng ta có thể bắt được những lỗi sảy ra do thay đổi mã nguồn.
- Chúng ta có thể kiểm thử từng thành phần riêng rẽ của dự án mà không cần đợi các thành phần khác hoàn thành.
- Do thực hiện test trên từng đơn vị nhỏ của các module riêng rẽ nên khi phát hiện lỗi cũng dễ dàng khoanh vùng và sửa chữa.
- Có thể tái sử dụng mã nguồn
- Chi phí cho việc sửa chữa lỗi trong giai đoạn unit test sẽ ít hơn so với các giai đoạn sau
- Mã nguồn đáng tin cậy hơn nếu viết tốt unit test
Khi làm Unit test chúng ta thường thấy các khái niệm sau:
Assertion: Là một phát biểu mô tả các công việc kiểm tra cần tiến hành, thí dụ: AreEqual(), IsTrue(), IsNotNull()… Mỗi một UT gồm nhiều assertion kiểm tra dữ liệu đầu ra, tính chính xác của các lỗi ngoại lệ ra và các vấn đề phức tạp khác như: – Sự tồn tại của một đối tượng – Điều kiện biên: Các giá trị có vượt ra ngoài giới hạn hay không – Thứ tự thực hiện của các luồng dữ liệu …
Test Point: Là một đơn vị kiểm tra nhỏ nhất, chỉ chứa đơn giản một assertion nhằm khẳng định tính đúng đắn của một chi tiết mã nào đó. Mọi thành viên dự án đều có thể viết một test point. Test Case: Là một tập hợp các test point nhằm kiểm tra một đặc điểm chức năng cụ thể, thí dụ toàn bộ giai đoạn người dùng nhập dữ liệu cho đến khi thông tin được nhập vào cơ sở dữ liệu. Trong nhiều trường hợp kiểm tra đặc biệt và khẩn cấp có thể không cần đến test case.
Test Suite: Là một tập hợp các test case định nghĩa cho từng module hoặc hệ thống con.
Regression Testing (hoặc Automated Testing): Là phương pháp kiểm nghiệm tự động sử dụng một phần mềm đặc biệt. Cùng một loại dữ liệu kiểm tra giống nhau nhưng được tiến hành nhiều lần lặp lại tự động nhằm ngăn chặn các lỗi cũ phát sinh trở lại. Kết hợp Regression Testing với Unit Testing sẽ đảm bảo các đoạn mã mới vẫn đáp ứng yêu cầu thay đổi và các đoạn mã cũ sẽ không bị ảnh hưởng bởi các hoạt động bảo trì.
Production Code: Phần mã chính của ứng dụng được chuyển giao cho khách hàng.
Unit Testing Code: Phần mã phụ để kiểm tra mã ứng dụng chính, không được chuyển giao cho khách hàng.
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
Trên đây là tóm lược sơ bộ về các định nghĩa của unit test, bài viết sau mình sẽ trình bày cụ thể các công cụ để viết unit test và ví dụ minh họa
[…] Unit test, chuyện chẳng của riêng devs nào! […]
[…] phải chị em QC quan tâm mà chính là anh em dev phải quan tâm đến. Bài viết “Unit test, chuyện chẳng của riêng devs nào!” bạn có thể đọc lại để hiểu thêm tại sao nó không thuộc phạm vi test […]
[…] [Testing] – Unit test + https://blog.ntechdevelopers.com/unit-test-la-gi/ + https://blog.ntechdevelopers.com/unit-test-chuyen-chang-cua-rieng-devs-nao/ – Integration test + https://blog.ntechdevelopers.com/integration-test-la-gi/ – […]