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

Lê Anh viết ngày 25/12/2015

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”

//Testcase đầu tiên của chúng ta
public void ReturnEmpty_WhenInputStringIsNullOrEmpty()
{
     StringUtil stringutil = new StringUtil();
     Assert.AreEqual(stringutil.RemoveSpace(null), "");
     Assert.AreEqual(stringutil.RemoveSpace(""), "");
}
//Đây là cài đặt đúng cho testcase trên
public string RemoveSpace(string input)
{
     return "";
}
//Cài đặt sai vì nó phức tạp hơn cần thiết
public string RemoveSpace(string input)
{
     if (string.IsNullOrEmpty(input))
     {
         return "";
     }
     return input;
}

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.

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

public void KếtQuả_WhenĐiềuKiệnĐầuVào()
public void KếtQuả_WhenMộtĐiềuGìĐóXảyRa()

public void ThrowLỗi_WhenĐiềuKiệnĐầuVào()
public void ThrowLỗi_WhenMộtĐiềuGìĐóXảyRa()

//ví dụ
public void ThrowNullReferenceException_WhenInputIsNull()
public void ReplaceUnderScoreSuccessfully_WhenInputStringIsNotNull()
public void ReturnEmpty_WhenInputStringIsNullOrEmpty()

//Ta cũng có 1 cách đặt tên khác như sau
public void ĐầuVào_ThenKếtQuả()
public void ĐiềuKiện_ThenKếtQuả()

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ụ

//tên unit test này gây khó hiểu cho người đọc
public void Successfull_WhenInputStringIsValid() 

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 ?
Nguồn : http://apollo13.vn/

Bình luận


White
{{ comment.user.name }}
Bỏ hay Hay
{{comment.like_count}}
Male avatar
{{ comment_error }}
Hủy
   

Hiển thị thử

Chỉnh sửa

White

Lê Anh

4 bài viết.
5 người follow
Kipalog
{{userFollowed ? 'Following' : 'Follow'}}
Cùng một tác giả
White
9 2
Chắc hẳn bạn đã từng phát ngấy khi viết media queries trong css theo kiểu này h2 { fontsize: 16px; } @media (minwidth: 768px) and (maxwidth: 1...
Lê Anh viết gần 3 năm trước
9 2
White
8 2
Về cơ bản có 3 phương pháp review code là review chéo (giữa 2 lập trình viên với nhau), cả team ngồi họp cùng review và cuối cùng là technical lead...
Lê Anh viết gần 3 năm trước
8 2
White
3 0
Trước đây mình có một bài viết về phương pháp (Link). Hôm nay mình sẽ giới thiệu với các bạn một phương pháp khác là startfish, tạm dịch là sao biể...
Lê Anh viết gần 3 năm trước
3 0
Bài viết liên quan
Male avatar
0 0
Swift TestDriven Development (TDD) Chapter 1 Part 2 Understanding TDD ===== Updated ngày 30/06 Updated một chút: Vì những bất tiện và không rõ r...
Bùi Khánh Duy viết 7 tháng trước
0 0
Male avatar
8 0
Test Driven Development (TDD) là một phương pháp có từ nhiều năm trước, các bạn luôn có thể search về nó và tại sao, làm sao để xài nó. Tuần này, m...
phucvin viết 3 năm trước
8 0
Male avatar
0 0
Swift TestDriven Development (TDD) Chapter 1 Part 3 Các lưu ý với Xcode === Updated ngày 30/06 Updated một chút: Vì những bất tiện và không rõ r...
Bùi Khánh Duy viết 7 tháng trước
0 0
{{like_count}}

kipalog

{{ comment_count }}

bình luận

{{liked ? "Đã kipalog" : "Kipalog"}}


White
{{userFollowed ? 'Following' : 'Follow'}}
4 bài viết.
5 người follow

 Đầu mục bài viết

Vẫn còn nữa! x

Kipalog vẫn còn rất nhiều bài viết hay và chủ đề thú vị chờ bạn khám phá!