Tôi có nên cấu trúc lại các bài kiểm tra đơn vị của mình khi tôi trích xuất một lớp ra khỏi System Under Test không?

Tôi đã viết lớp này làm một vài điều (có lẽ đây là vi phạm Nguyên tắc Trách nhiệm duy nhất). Bây giờ tôi nhận ra rằng một số phần khác của dự án cần một phần logic đó và cách tôi sẽ trình bày nó là trích xuất một lớp ra khỏi Hệ thống Kiểm tra ban đầu của tôi.

Tôi dự đoán có thể làm điều này mà không phải thay đổi bất kỳ mã kiểm tra nào, nhưng khi tôi hoàn thành, bạn có thể lập luận rằng bài kiểm tra không còn là bài kiểm tra đơn vị nữa. Nó sẽ kiểm tra lớp gốc và lớp tôi đã trích xuất. Nói cách khác, tôi sẽ có một trường hợp thử nghiệm, nhưng hai hệ thống đang được thử nghiệm.

Tôi có phải cấu trúc lại mã kiểm tra sau khi hoàn thành không? IE: Tạo ExtractedClassTest và di chuyển tất cả các bài kiểm tra có liên quan từ OriginalClassTest vào đó? Điều này có vẻ như có một chút rủi ro: Tôi có thể mất một số phạm vi bảo hiểm trong quá trình, nó có thể không đơn giản như di chuyển một bài kiểm tra và cuối cùng tôi đã viết lại một số mã kiểm tra mà tôi biết đã từng làm việc nhưng có thể không còn nữa, Vân vân.

Mặt khác, nếu tôi rời khỏi OriginalClassTest, tôi có thể thấy đây là sự cố bảo trì thử nghiệm. Sẽ hơi khó hiểu khi tìm thấy các bài kiểm tra của ExtractedClass. Ấn tượng đầu tiên của bạn sẽ là nó không tồn tại. Theo thời gian với rất nhiều tái cấu trúc mã sản xuất, điều này có thể trở thành một vấn đề nghiêm trọng.

Tôi mới tham gia TDD nên tôi muốn một lời khuyên của chuyên gia. Cảm ơn!

Sau khi xem cuộc nói chuyện tuyệt vời này "Ian Cooper: TDD, mọi chuyện đã sai ở đâu", tôi sẽ không đồng ý với @pdr. Tôi nghĩ bạn chỉ nên giữ các bài kiểm tra ban đầu. Khả năng của bạn để cấu trúc lại hệ thống của bạn đang được kiểm tra mà không phá vỡ, viết hoặc thay đổi bất kỳ bài kiểm tra nào là toàn bộ mục đích của việc viết bài kiểm tra ở nơi đầu tiên.

Nếu tôi kiểm tra lớp trích xuất, tôi sẽ kiểm tra việc thực hiện hơn là hành vi. Do đó, mã của tôi sẽ khó tái cấu trúc hơn trong tương lai: Những thử nghiệm mới này có thể sẽ thất bại ngay cả khi hành vi vẫn hoạt động.

Trong thời gian phát triển, có cả hai. Giữ các bài kiểm tra cũ để đảm bảo rằng bạn chưa phá vỡ bất cứ điều gì, hãy viết các bài kiểm tra mới (từ đầu) để giúp bạn thiết kế các lớp như bình thường.

Cuối cùng, chạy qua và loại bỏ bất cứ thứ gì không còn tồn tại trong các bài kiểm tra cũ. Hãy cẩn thận trong phân tích này; đừng xóa cái gì đó vì bạn nghĩ nó không còn tồn tại. Hãy chứng minh cho chính bạn (hoặc người khác hoặc vịt cao su) tại sao không cần thiết nữa. Phá vỡ bài kiểm tra và chắc chắn rằng một bài kiểm tra khác phá vỡ nó.

Bất cứ điều gì còn lại trong các bài kiểm tra cũ nên được thực hiện trên cơ sở từng trường hợp cụ thể, nhưng chủ yếu chúng nên được viết lại vào cấu trúc mới.

Bởi vì bạn đúng, bạn không muốn bị bỏ lại với một cơn ác mộng bảo trì. Nhưng bạn không muốn phạm vi bảo hiểm ít hơn so với trước đây.