Quá nhiều phương pháp công cộng bị bắt buộc bởi phát triển thử nghiệm theo hướng

Question

Câu hỏi rất cụ thể từ người mới đến TDD:

Tôi tách riêng các thử nghiệm và ứng dụng của mình thành các gói khác nhau. Do đó, hầu hết các phương pháp ứng dụng của tôi phải được công khai để kiểm tra truy cập chúng. Khi tôi tiến bộ, rõ ràng là một số phương pháp có thể trở thành riêng tư, nhưng nếu tôi thực hiện thay đổi đó, các thử nghiệm truy cập chúng sẽ không hoạt động. Tôi đang thiếu một bước, hoặc làm điều gì đó sai trái, hay đây chỉ là một sự sụp đổ của TDD?

Answer 1

Đây không phải là một sự sụp đổ của TDD, mà là một cách tiếp cận để kiểm tra tin rằng bạn cần kiểm tra mọi thuộc tính và mọi phương pháp. Trong thực tế, bạn không nên quan tâm đến các phương thức riêng khi thử nghiệm vì chúng chỉ nên tồn tại để tạo điều kiện cho một số phần công cộng của API.

Không bao giờ thay đổi điều gì đó từ riêng tư thành công khai cho mục đích thử nghiệm!

Bạn chỉ nên cố gắng xác minh hành vi hiển thị công khai. Phần còn lại là các chi tiết triển khai và bạn đặc biệt muốn tránh kiểm tra các chi tiết đó. TDD có nghĩa là để cung cấp cho bạn một bộ các bài kiểm tra sẽ cho phép bạn dễ dàng thay đổi các chi tiết thực hiện mà không vi phạm các bài kiểm tra (hành vi thay đổi).

Cho phép nói rằng tôi có loại: MyClass và tôi muốn thử nghiệm phương pháp DoStuff. Tất cả những gì tôi quan tâm là phương thức DoStuff có ý nghĩa gì đó và trả về kết quả mong đợi. Nó có thể gọi một trăm phương pháp riêng tư để đạt được điểm đó, nhưng tôi không quan tâm như người tiêu dùng của phương pháp đó.

Answer 2

Bạn không chỉ định ngôn ngữ bạn đang sử dụng, nhưng chắc chắn trong hầu hết các bạn có thể đặt các bài kiểm tra theo cách có quyền truy cập đặc quyền hơn vào lớp. Trong Java, ví dụ, kiểm thử có thể nằm trong cùng một gói, với tệp lớp thực tế nằm trong một thư mục khác, do đó nó tách biệt với mã sản xuất.

Tuy nhiên, khi bạn đang thực TDD, các bài kiểm tra sẽ hướng thiết kế lớp, vì vậy nếu bạn có phương pháp chỉ để kiểm tra một số chức năng, bạn có thể (không phải lúc nào) làm điều gì đó sai, và bạn nên xem xét kỹ thuật như tiêm phụ thuộc và chế nhạo để hướng dẫn thiết kế của bạn tốt hơn.

Answer 3

Ít nhất trong Java, thực hành tốt là có hai cây nguồn, một cho mã và một cho thử nghiệm. Vì vậy, bạn có thể đặt mã và các thử nghiệm của mình trong cùng một gói, trong khi chúng vẫn nằm trong các thư mục khác nhau:

src/org/my/xy/X.java 
test/org/my/xy/TestX.java 

Sau đó, bạn có thể đặt gói phương thức riêng tư.

Answer 4

Đây là câu nói cũ, "TDD là về thiết kế", thường xuyên xuất hiện. Một lớp học với quá nhiều phương pháp công cộng có thể có quá nhiều trách nhiệm - và thực tế là bạn đang lái thử, nó chỉ phơi bày điều đó; nó không gây ra vấn đề.

Khi bạn thấy mình trong tình huống này, giải pháp tốt nhất là thường xuyên tìm một số tập con của phương thức công khai có thể được trích xuất vào một lớp mới ("lớp mầm"), sau đó cho lớp ban đầu của bạn một biến mẫu của lớp nảy mầm. Các phương thức công khai xứng đáng được công khai trong lớp mới, nhưng bây giờ chúng - đối với API của lớp gốc - riêng tư. Và bây giờ bạn đã tuân thủ tốt hơn với SRP, khớp nối lỏng hơn, sự gắn kết thấp hơn - thiết kế tốt hơn.

Tất cả vì các tính năng tiếp xúc của TDD trong lớp học của bạn mà nếu không sẽ bị trượt dưới radar. TDD về Thiết kế.