Một số sai lầm khi thực hành TDD

1. Viết code trước

Những người mới bắt tay vào làm TDD thường mắc phải 1 sai lầm cơ bản đó là viết code trước sau đó mới viết test. Khi được hỏi là tại sao lại làm như vậy thì họ có muôn vàn lý do để giải thích

– Viết cái gì trước mà chẳng được, test trước hay code trước cũng chẳng khác gì nhau cả.

– Viết test trước thì hơi khó nên mình viết code trước cũng được mà

– Do thói quen viết code trước rồi, khó sửa lắm

– Chỉ có mỗi hàm này là mình viết code trước thôi, các hàm khác mình vẫn áp dụng TDD mà !

2. Sửa code trước sau đó mới sửa unit test

Trong thực tế làm agile thì yêu cầu khách hàng có thể thay đổi liên tục, việc sửa lại những đoạn code cũ là chuyện xảy ra như cơm bữa. Nhưng điều đáng nói ở đây là hầu hết chúng ta hay mắc sai lầm là sửa nội dung hàm cho đúng yêu cầu trước, sau đó mới sửa unit test vì việc này dễ dàng và có vẻ nhanh hơn. Nhưng mà tớ khuyên thật, hãy quên cách làm này đi vì nó tiềm ẩn rất nhiều nguy cơ lỗi sau này. Rồi lúc đó lại than vãn “Mình áp dụng TDD mà chẳng có hiệu quả gì cả @@”

3. Viết code nhiều hơn mức cần thiết

Một sai lầm cơ bản tiếp theo đó là khi viết code cho các testcase pass thì chúng ta lại viết nhiều hơn mức cần thiết. Ví dụ testcase đầu tiên của chúng ta là “trả về rỗng khi tham số đầu vào null hoặc rỗng”

Hãy nhớ rằng chỉ viết lượng code vừa đủ để testcase pass, không nên viết nhiều hơn vì như vậy nó sẽ quay trở về trường hợp lỗi cơ bản “Viết code trước khi viết unit test”

4. Thừa hoặc thiếu testcase

Nhiều người tâm niệm thừa còn hơn thiếu vì như vậy mới chắc chắn, nhưng thực tế thì nó chỉ gây rối thêm mà thôi, thậm chí gây khó chịu cho người đọc. Sau này bảo trì thì bạn sẽ phải tốn thêm thời gian đọc những thứ không cần thiết. Còn nếu thiếu testcase thì chẳng có gì đảm bảo là chức năng mà bạn viết ra sẽ hoạt động đúng cả. Vì vậy hãy cố mà tránh xa nó ra, lỗi này chủ yếu xảy ra khi chúng ta chưa có nhiều kỹ năng về unit test. Nhưng không sao, hãy để apollo13 giúp bạn (ít nhất thì cũng là unit test trong C#)

5. Không chạy lại tất cả các testcase

Nhiều người chẳng bao giờ có thói quen chạy lại tất cả các test case sau khi hoàn tất công việc của mình. Chủ yếu hành động này đến từ 2 suy nghĩ phổ biến sau :

– Những unit test trước đã pass rồi thì chạy lại vẫn cứ pass thôi (Lạc quan quá mức hoặc do thiếu hiểu biết, sửa 1 hàm nhưng có tới 10 chỗ khác sử dụng hàm đó thì tất cả sẽ fail)

– Quên mất không chạy (thường xảy ra khi chưa thành thạo TDD)

6. Thực hiện testcase tiếp theo trong khi vẫn còn testcase fail

Đây không phải là cuộc chạy đua xem ai viết được nhiều test case hơn, chính vì vậy mà hãy tập trung hoàn thiện test case đang fail sau đó mới làm test case khác. Vì trì hoãn không bao giờ là tốt cả, nhất lại là trì hoãn bug. Trong trường hợp bạn không thể viết cho test case đó pass (do khó, yếu tố môi trường, dữ liệu….) thì hãy đánh dấu testcase đó là ignore hoặc comment lại.

7. Refactoring code trong khi vẫn có testcase fail

Thực ra đây cũng không hẳn là một sai lầm, bởi vì bạn refactor code để sửa cho cái test case đang fail đó thành đúng. Nhưng nếu bạn thực hiện một refactor ở mức “quy mô” thì cần xem xét lại hành động này của mình.

8. Tên unit test đặt không đúng quy tắc

Bạn nên nhớ rằng, testcase ngoài nhiệm vụ chính là kiểm thử ra thì nó cũng giúp cho người đọc code biết được nội dung thiết kế của hàm đó như thế nào. Đôi khi chỉ cần nhìn qua các testcase của 1 hàm là có thể hình dung được thiết kế và nghiệp vụ của hàm đó ra sao. Chính vì vậy mà việc đặt tên sao cho có ngữ nghĩa là một điều rất quan trọng. Bạn có thể áp dụng quy tắc như dưới đây

Chúng ta nên tránh sử dụng nhiều dấu gạch chân vì rất rối (tốt nhất chỉ nên dùng một). Một số trường hợp áp dụng quy tắc trên nhưng tên unit test vẫn không đảm bảo được ngữ nghĩa, ví dụ

Nếu chỉ nhìn tên trên bạn có thể hiểu thành công(Successfull) và hợp lệ(Valid) trong trường hợp này nghĩa là gì không ?