- vừa được xem lúc

Viết Unit Test sao cho Clean - Bài học từ Clean Code

0 0 1

Người đăng: David Sam

Theo Viblo Asia

Unit Test có cần phải "clean" không?

Bạn đã bao giờ rơi vào tình huống phải sửa một đoạn code và ngay lập tức nhận về hàng loạt lỗi test không? Nhưng khi nhìn vào test case, bạn chẳng hiểu nổi chúng đang kiểm tra cái gì. Nếu có, chào mừng bạn đến với thế giới của unit test kém chất lượng.

Robert C. Martin (Uncle Bob) trong cuốn Clean Code nhấn mạnh rằng unit test cũng cần phải clean như code sản phẩm. Vì sao ư? Vì nếu test code lộn xộn, nó không giúp ta tự tin sửa code mà ngược lại còn gây thêm rắc rối.

Tại sao phải coi Unit Test là "công dân hạng nhất"?

Trong thế giới lập trình, code sản phẩm thường được ưu tiên hàng đầu, còn test code thì bị xem như phần phụ. Nhưng hãy tưởng tượng bạn đang xây một cây cầu, liệu bạn có muốn thử tải trọng sau khi hoàn tất, hay muốn kiểm tra từng bước khi thi công?

Nếu ta viết test cẩu thả, đến một ngày nào đó, khi test thất bại, ta sẽ tốn rất nhiều thời gian để hiểu tại sao nó lại hỏng. Đó là lý do ta cần viết unit test sao cho rõ ràng, dễ đọc và dễ bảo trì.

Ba luật của TDD - Có thực sự cần thiết? Test-Driven Development (TDD) đề xuất ba luật:

  • Viết test trước khi viết code.
  • Viết đủ code để test chạy pass.
  • Viết đủ test để chứng minh code đang hoạt động đúng. Nếu bạn chưa quen với TDD, bạn có thể nghĩ "Thế này mất thời gian quá!". Nhưng thực tế, khi tuân theo quy tắc này, bạn sẽ có một bộ test giúp bạn tự tin thay đổi code mà không lo phá vỡ chức năng cũ.

Làm thế nào để viết Unit Test "sạch"?

1. Viết test dễ đọc, dễ hiểu

Test case là tài liệu sống của dự án. Khi test dễ đọc, chúng giúp ta (và đồng đội) hiểu rõ hệ thống đang hoạt động như thế nào.

Ví dụ:

func TestCalculateDiscount_GoldMember_ShouldApply20PercentDiscount(t *testing.T) { // Arrange user := User{Membership: "Gold"} // Act discount := CalculateDiscount(user) // Assert if discount != 0.2 { t.Errorf("Expected 20%% discount, got %f", discount) }
}

2. Mỗi test chỉ kiểm tra một điều

Nếu một test kiểm tra quá nhiều thứ, khi nó thất bại, ta sẽ khó xác định nguyên nhân. Hãy giữ mỗi test ngắn gọn, tập trung vào một hành vi duy nhất.

3. Áp dụng nguyên tắc FIRST

Unit test sạch sẽ tuân theo 5 tiêu chí FIRST:

  • Fast - Chạy nhanh.
  • Independent - Độc lập, không phụ thuộc test khác.
  • Repeatable - Luôn cho kết quả như nhau.
  • Self-validating - Tự động kiểm tra đúng/sai.
  • Timely - Viết test đúng thời điểm, tốt nhất là trước khi code.

4. Tránh "fragile tests"

Test không nên dễ hỏng chỉ vì ta thay đổi một chút về implementation. Hãy tập trung test kết quả mong muốn, không phải cách thức thực hiện. Ví dụ, thay vì kiểm tra xem hàm có gọi một method nội bộ hay không, hãy kiểm tra đầu vào - đầu ra.

Kết luận

Viết unit test sạch giúp bạn tự tin thay đổi code mà không lo làm hỏng chức năng khác. Nó không chỉ giúp phát hiện lỗi sớm mà còn là tài liệu quan trọng cho cả nhóm. Hãy nhớ: code sạch thì test cũng phải sạch. Nếu một test case khiến bạn mất quá nhiều thời gian để hiểu, có lẽ nó cần được refactor! Bạn có từng gặp trường hợp test code quá rối rắm chưa? Chia sẻ với mình nhé! 🚀

Bình luận

Bài viết tương tự

- vừa được xem lúc

Học Regular Expression và cuộc đời bạn sẽ bớt khổ (Updated v2.2)

. Regular Expression (RegEx) à? Nghe quen quen. . Bạn cần xử lý validate (kiểm tra tính hợp lệ) các trường dữ liệu nhập vào ô Text. .

0 0 112

- vừa được xem lúc

Naming rules - Các quy tắc vàng trong làng đặt tên

. . Đã bao giờ bạn gặp khó khăn khi phải suy nghĩ nên đặt tên biến/hàm như thế nào trong lúc code.

0 0 34

- vừa được xem lúc

Tóm tắt cuốn Clean Code của Uncle Bob

Bài viết được dịch từ Gist của wojteklu. . Quy tắc chung. .

0 0 103

- vừa được xem lúc

Tôi đi học code - lớp mẫu giáo

Chào mừng các bạn quay trở lại với blog duthaho.com.

0 0 61

- vừa được xem lúc

Lean Code CSS

Khi thiết kế và phát triển web, đôi lúc chúng ta gặp khó khăn trong việc tổ chức và quản lý code CSS. Nhiều nhà thiết kế website nghĩ rằng việc tổ chức và quản lý code thật là rắc rối, tuy nhiên nếu b

0 0 34

- vừa được xem lúc

Design Patterns là gì? Tại sao nó lại là trợ thủ đắc lực của Developers

Design Pattern là một giải pháp chung để giải quyết các vấn đề phổ biến khi thiết kế phần mềm trong lập trình hướng đối tượng OOP. Design pattern là các giải pháp tổng thể đã được tối ưu hóa, được tái

0 0 61