Tôi có nên viết một bài kiểm tra để chứng minh rằng việc xóa mã sửa lỗi không?

Thỉnh thoảng tôi sẽ gặp phải tình huống sửa lỗi yêu cầu tôi xóa một phần mã. Người theo chủ nghĩa thuần túy TDD sẽ (tôi giả sử) ủng hộ việc viết một bài kiểm tra thất bại, xóa mã, sau đó xem bài kiểm tra.

Bây giờ, có vẻ như thực sự kỳ lạ khi có một thử nghiệm khẳng định rằng một số mã đã bị xóa. Chắc chắn, tôi cho rằng nó sẽ đảm bảo không ai đào sâu vào kiểm soát nguồn và đưa mã đó trở lại, nhưng nó có đáng không? Nếu nó có giá trị, nó chắc chắn có vẻ ít giá trị hơn so với việc viết một bài kiểm tra mã đã được thêm vào , phải không?

unit-testing tdd bug

— jhewlett
nguồn

Tôi nghĩ rằng bất kỳ kiểm tra hồi quy nào cũng hữu ích, bất kể cách sửa lỗi

— Ismail Badawi

Thử nghiệm không xác nhận mã đã bị xóa - thử nghiệm khẳng định lỗi đã được sửa ...

— user253751

Bạn đang nhìn nó sai cách. Thử nghiệm không khẳng định rằng mã đã được gỡ bỏ. Các thử nghiệm không khẳng định một chức năng nhất định.

Bài kiểm tra không quan tâm đến số lượng mã cần thiết để vượt qua, và cũng không nhận ra rằng bạn đã xóa một số mã. Giá trị của việc kiểm tra như vậy cũng giống như bất kỳ thử nghiệm nào khác mà bạn tạo ra do lỗi: bạn tự tin không có lỗi khi thử nghiệm vượt qua và tích hợp thử nghiệm vào quy trình xây dựng đảm bảo cho bạn rằng lỗi sẽ nhiều khả năng không được giới thiệu lại.

Một cách khác để xem xét nó từ góc độ TDD là như sau: Khi bạn biết rằng việc xóa mã sẽ sửa lỗi và sau đó bạn tự hỏi liệu có nên viết một bài kiểm tra hay không, bạn đã làm sai TDD. Khi bạn bắt đầu làm việc với lỗi, trước tiên bạn nên viết bài kiểm tra để đảm bảo sự hiện diện của lỗi bằng cách thất bại. Chỉ sau đó, bạn mới sửa lỗi thực tế - có thể yêu cầu xóa mã hoặc không - và thực hiện kiểm tra vượt qua. Câu hỏi bạn đang hỏi thậm chí không phát sinh theo cách đó.

— Frank
nguồn

+1, nhưng tôi có thể tưởng tượng tình huống sau: mã bị xóa có chứa một số chức năng vô lý mà ai đó đã thêm không hiểu chính xác miền vấn đề. Bây giờ, trong quá trình xem xét mã, một nhà phát triển khác thấy rằng toàn bộ phần này thực sự vô nghĩa và mã sẽ bị xóa. Có rất nhiều bài kiểm tra cho hành vi vô nghĩa như vậy có thể làm nở bộ thử nghiệm của bạn.

— Doc Brown

Rõ ràng chức năng loại bỏ xử lý một số đầu vào / đầu ra sai. Rõ ràng ai đó ở xa hơn có thể hiểu sai vấn đề theo cùng một cách. Nếu bạn sợ bộ thử nghiệm phình to, tôi không nghĩ TDD là dành cho bạn. Thử nghiệm phù hợp với bloat là gì?

— Dorus

@DocBrown: Nếu họ đang làm TDD, thì phải có một số thử nghiệm yêu cầu chức năng vô lý đó, nếu không họ thậm chí sẽ không được phép viết mã đó ngay từ đầu! Hãy nhớ rằng, bạn chỉ được phép viết số lượng mã tối thiểu tuyệt đối để vượt qua bài kiểm tra. Nếu có không phải là một thử nghiệm như vậy, sau đó mã nên không bao giờ được viết ở nơi đầu tiên và nó chỉ có thể bị xóa. Nếu có là một bài kiểm tra đó lực lượng rằng hành vi ngớ ngẩn, sau đó kiểm tra đó cần được loại bỏ, và bây giờ chúng ta đang ở cùng một vụ án tôi đã mô tả trước đây: các thử nghiệm đã biến mất, xóa các mã.

— Jörg W Mittag

Trong cả hai trường hợp, bạn không bao giờ thêm bất kỳ thử nghiệm nào vào bộ thử nghiệm và trong trường hợp thứ hai, bạn thậm chí loại bỏ một thử nghiệm. Tuy nhiên, nếu nó chỉ ra rằng thử nghiệm thực sự có ý nghĩa, thì, sau đó tất cả các chức năng không quá vô lý.

— Jörg W Mittag