Sử dụng lại các triển khai thử nghiệm trong JUnit 4?

Question

Tôi có một giao diện, ví dụ .:

public interface Thing { 
    FrobResult frob(FrobInput); 
} 

Và một số triển khai các giao diện đó (ví dụ NormalThing, ImmutableThing, AsyncThing) mà tôi đang cố gắng thử nghiệm.

Nhiều phương pháp thử nghiệm của tôi thực sự đảm bảo rằng giao diện được triển khai chính xác và do đó được nhân đôi trên mỗi lần triển khai Thing. Trong JUnit 3, một giải pháp phổ biến cho việc này là tạo một lớp cơ sở (mở rộng TestCase) mà sau đó được phân lớp theo từng lớp thực hiện. Nhưng đây có phải là cách tiếp cận chính xác cho JUnit 4 không?

lựa chọn thay thế có thể xảy ra trong (Tôi tin) thứ tự tăng dần ưu tiên:

1. cut'n'paste các phương pháp kiểm tra trùng lặp. Không phải là DRY chút nào, nhưng tôi đoán ít đáng lo ngại trong các bài kiểm tra hơn là trong mã sản xuất.

2. Tạo lớp trừu tượng với các phương thức @Test và phân lớp nó cho từng lớp thử nghiệm triển khai. (Thường thấy với các bài kiểm tra JUnit 3 - đây có phải là cách tốt để đi vào JUnit 4 không?)

3. Đặt các phương thức thử nghiệm chung vào một lớp trợ giúp và gọi nó trên mỗi lần thực hiện. (Thành phần thay vì thừa kế.)

Cách tốt nhất để thực hiện # 3 là gì? Có thể thử nghiệm @RunWith(Parameterized.class) được tham số hóa với từng triển khai? Hoặc là có một cách tốt hơn để thực hiện điều này?

Answer 1

Có, đó là cách tiếp cận chính xác để tạo lớp cơ sở sau đó được phân lớp theo từng lớp triển khai trong JUnit4.

Tôi thích lớp kiểm tra cơ sở cho giao diện là trừu tượng, tức là "thay thế" 2 của bạn, vì tôi đã có kinh nghiệm tốt trong việc bắt chước phân cấp thừa kế từ mã sản xuất cho mã thử nghiệm. Vì vậy, nếu bạn có giao diện I và triển khai S1, S2 và S3, bạn thực hiện các lớp thử nghiệm trừu tượng TestI và các lớp học thử nghiệm TestS1, TestS2 và TestS3.

Các trường hợp kiểm tra nên nói, tức là kể một câu chuyện. Bằng cách chọn - như mọi khi - tên phương thức cẩn thận và chỉ sử dụng kiểu phân loại hành vi sạch, thì sự thừa kế không làm xáo trộn điều này.

Answer 2

Tôi sử dụng phương pháp # 2 cho các trường hợp kiểm tra JUnit và TestNG. Điều này là thuận tiện nhất và dễ bảo trì. Nó cũng thẳng về phía trước để chọn (kể từ khi nó có nguồn gốc từ OOD để có lớp cơ sở có phương pháp phổ biến). Đối với tôi, các lớp kiểm tra đơn vị không khác với các lớp dự án thông thường ... vì vậy tôi áp dụng các cân nhắc thiết kế tương tự.