Quá trình hành động tốt nhất trong TDD là gì, sau khi thực hiện logic một cách chính xác, thử nghiệm vẫn thất bại (vì có một lỗi trong thử nghiệm)?
Ví dụ: giả sử bạn muốn phát triển chức năng sau:
int add(int a, int b) {
return a + b;
}
Giả sử chúng tôi phát triển nó theo các bước sau:
Kiểm tra viết (chưa có chức năng):
// test1 Assert.assertEquals(5, add(2, 3));
Kết quả trong lỗi biên dịch.
Viết một thực hiện chức năng giả:
int add(int a, int b) { return 5; }
Kết quả:
test1
vượt qua.Thêm một trường hợp thử nghiệm khác:
// test2 -- notice the wrong expected value (should be 11)! Assert.assertEquals(12, add(5, 6));
Kết quả:
test2
thất bại,test1
vẫn vượt qua.Viết thực hiện:
int add(int a, int b) { return a + b; }
Kết quả:
test1
vẫn vượt qua,test2
vẫn thất bại (kể từ đó11 != 12
).
Trong trường hợp cụ thể này: sẽ tốt hơn nếu:
- chính xác
test2
, và thấy rằng bây giờ nó đi qua, hoặc - xóa phần thực hiện mới (tức là quay lại bước # 2 ở trên), sửa
test2
và để nó thất bại, sau đó giới thiệu lại cách thực hiện đúng (bước # 4. ở trên).
Hoặc có một số cách khác, thông minh hơn?
Mặc dù tôi hiểu rằng vấn đề ví dụ khá tầm thường, tôi quan tâm đến việc phải làm gì trong trường hợp chung, có thể phức tạp hơn việc cộng hai số.
EDIT (Đáp lại câu trả lời của @Thomas Junk):
Trọng tâm của câu hỏi này là những gì TDD gợi ý trong trường hợp như vậy, không phải là "thực tiễn tốt nhất phổ quát" để đạt được mã hay bài kiểm tra tốt (có thể khác với cách TDD).