Viết unit test là một phần quan trọng của quá trình phát triển phần mềm bởi khi làm chính xác và hiệu quả, bạn có thể giảm đáng kể số lượng bug và đẩy nhanh tiến độ công việc.

*Hãy cùng Gambaru xem qua một số cách tiếp cận viết unit test sau! Nguồn ảnh: freepik*

Kiểm thử phương thức (method) với business logic

Giả sử ta có lớp Story với phương thức publish. Ta chỉ được phép publish một story nếu nó có trạng thái DRAFT.

Kiểm thử phương thức với Business Logic — *Xem code gốc.*

Trong trường hợp này, sẽ hợp lý nếu viết bài unit test cho phương thức này bởi nó chứa một quy tắc nghiệp vụ quan trọng.

Ta cần tạo hai bài unit test để bao quát hoàn toàn được quy tắc này:

Kiểm tra xem có xuất hiện Error khi trạng thái không phải là DRAFT hay không.
Kiểm tra xem liệu trạng thái có chuyển đổi thành Published khi trạng thái là DRAFT hay không.

Chỉ bằng cách kiểm thử phương thức, ta có thể giữ cho các bài unit test ở mức nhỏ. Điều này đặc biệt hữu ích khi kiểm tra business logic khó.

Hãy cố gắng luôn bao quát mọi nhánh trong business logic của mình.

Ngoài ra, sử dụng công cụ báo cáo code coverage để thống kê phần trăm code đã được kiểm thử cũng là một thực tiễn tốt.

Giả lập các thành phần phụ thuộc

Trong một số trường hợp, để đảm bảo rằng mình chỉ đang kiểm tra business logic, bạn sẽ cần giả lập các thành phần phụ thuộc (mock the dependencies). Hãy sử dụng ví dụ sau:

Dịch vụ này có một phụ thuộc vào một event dispatcher. Cần phải giả lập phụ thuộc này vì ta không muốn dispatch MoneyTransferredEvent trong quá trình tiến hành làm unit test.

Ta chỉ muốn biết liệu dịch vụ này có xử lý tất cả các business logic như mong đợi hay không.

Giả lập các thành phần phụ thuộc — *Xem code gốc.*

Khi giả lập phụ thuộc này, ta có thể thay thế triển khai thực tế bằng triển khai “giả” (fake implementation) và sử dụng triển khai giả này để kiểm tra xem phương thức chính xác đã được gọi hay chưa.

Một giả lập cũng có thể trả về dữ liệu. Điều này có thể hữu ích khi ta giả lập repository chẳng hạn.

Hãy giữ các bài unit test ở mức độ nhỏ và chi tiết. Nếu có các assertion không liên quan trong một bài unit test, bạn có thể xem xét việc tách chúng thành nhiều bài unit test. Dưới đây là một ví dụ:

Tách thành nhiều bài unit test — *Xem code gốc.*

Bằng cách tách các assertion này ra, bạn sẽ biết trực tiếp phần nào của ứng dụng không hoạt động khi bài unit test không thành công.

Kiểm thử mô-đun

Đôi khi, sẽ hữu ích hơn khi kiểm thử toàn bộ mô-đun thay vì viết một bài unit test cho mọi phương thức.

Giả sử chúng ta có một số code cho cronjob trong ứng dụng của mình. Cronjob này sẽ tìm lấy tất cả các story đang chờ và publish chúng:

Điều quan trọng duy nhất đối với mô-đun này là nó lấy các story và publish từng story một. Viết một bài kiểm thử cho một mô-đun như thế này mang lại một số lợi ích tuyệt vời sau:

Bạn chỉ có thể kiểm tra những gì quan trọng: Các endpoint chính xác có được gọi với dữ liệu chính xác không?
Bạn có thể dễ dàng tái cấu trúc code của mình. Bài kiểm thử sẽ pass miễn là các endpoint được gọi với dữ liệu mong đợi.
Việc kiểm thử một mô-đun thường có thể được thực hiện nhanh hơn so với việc viết một bài kiểm thử cho mọi phương thức.

Hãy cùng xem qua bài kiểm thử mô-đun dưới đây:

Bằng cách giả lập API client, ta có thể trả về hai story. Kiểm thử sẽ pass nếu hai story này cũng được publish. Thêm một số bài kiểm thử khác cho các kết quả API khác nhau cũng là một ý hay.

Một lựa chọn tốt khác để kiểm thử các mô-đun là viết các bài kiểm tra tích hợp (integration test).

Tuy nhiên, lợi ích của làm unit test là bạn có thể dễ dàng chạy nó cục bộ hoặc trong một pipeline. Các bài kiểm thử mô-đun này cũng rất hữu ích cho phát triển hướng kiểm thử (test-driven development – TDD).

Nếu mô-đun chứa nhiều business logic, bạn có thể muốn thêm một số bài kiểm thử cho các quy tắc nghiệp vụ cụ thể này.

Khi bao quát được business logic trong các bài kiểm thử phương thức, các bài kiểm thử mô-đun sẽ trở nên đơn giản.

Các bài kiểm thử mô-đun sẽ vẫn hữu ích để xác nhận xem liệu tất cả các lớp có hoạt động cùng nhau như mong đợi hay không.

Kết

Tôi cực kỳ chuộng kiểm thử mô-đun vì chúng bao quát được rất nhiều code. Chúng cũng có thể hữu ích để kiểm thử dependency injection.

Tuy nhiên, chỉ viết các bài kiểm thử mô-đun thường sẽ không đủ. Sự kết hợp các bài kiểm thử mô-đun và kiểm thử phương thức sẽ mang đến nhiều lợi ích mỹ mãn.

Một điều quan trọng khác cần lưu ý là có nhiều bài kiểm thử phương thức quá có thể làm bạn chậm lại.

Ví dụ, khi thay đổi một chuỗi thành một enum, hầu hết các bài kiểm thử sẽ không thành công.

Tuy nhiên, các bài kiểm thử mô-đun vẫn sẽ pass. Vì vậy, hãy cân nhắc việc chỉ viết các bài kiểm thử này cho các phương thức chứa business logic.

Nếu bạn chưa bao giờ viết một bài unit test, lời khuyên là bạn nên bắt đầu bằng việc thử nghiệm các phương pháp nhất định.

Các bài kiểm thử mô-đun có thể hơi gian nan, phức tạp hơn – đặc biệt nếu chúng có nhiều thành phần phụ thuộc.

*Quan trọng nhất là các bài kiểm thử của bạn bao quát hết logic quan trọng nhất và giúp cải thiện chất lượng code của mình. Ảnh: freepik*

Để viết được các bài unit test hiệu quả, bạn sẽ cần tách code của mình đúng cách. Hãy tuân theo nguyên tắc SOLID.

Việc tách dự án của bạn thành các lớp khác nhau bằng cách sử dụng kiến trúc đa tầng (multitier architecture) chẳng hạn, cũng có thể giúp việc kiểm thử ứng dụng dễ dàng hơn.

Theo Stein Janssen

undefined undefined

1 Result qc-engineer found