Trước hết, here's a great article with tips on unit testing. Thứ hai, tôi tìm thấy một cách tuyệt vời để tránh thực hiện tấn thay đổi trong mã cũ là chỉ refactor nó một chút cho đến khi bạn có thể kiểm tra nó. Một cách dễ dàng để làm điều này là làm cho các thành viên riêng được bảo vệ, và sau đó ghi đè lên trường được bảo vệ.
Ví dụ: giả sử bạn có một lớp tải một số nội dung từ cơ sở dữ liệu trong quá trình khởi tạo. Trong trường hợp này, bạn không thể chỉ ghi đè lên một phương thức được bảo vệ, nhưng bạn có thể trích xuất logic DB thành một trường được bảo vệ và sau đó ghi đè lên nó trong thử nghiệm.
public class MyClass {
public MyClass() {
// undesirable DB logic
}
}
trở thành
public class MyClass {
public MyClass() {
loadFromDB();
}
protected void loadFromDB() {
// undesirable DB logic
}
}
và sau đó thử nghiệm của bạn trông giống như sau:
public class MyClassTest {
public void testSomething() {
MyClass myClass = new MyClassWrapper();
// test it
}
private static class MyClassWrapper extends MyClass {
@Override
protected void loadFromDB() {
// some mock logic
}
}
}
Đây là phần nào của một tấm gương xấu, bởi vì bạn có thể sử dụng DBUnit trong trường hợp này, nhưng tôi thực sự đã làm điều này trong một trường hợp tương tự gần đây vì tôi muốn kiểm tra một số chức năng hoàn toàn không liên quan đến dữ liệu đang được tải, vì vậy nó rất hiệu quả. Tôi cũng tìm thấy việc phơi bày các thành viên như vậy có ích trong các trường hợp tương tự khác mà tôi cần phải loại bỏ một số phụ thuộc đã ở trong một lớp học trong một thời gian dài.
Tôi khuyên bạn nên chống lại giải pháp này nếu bạn đang viết một khuôn khổ mặc dù, trừ khi bạn thực sự không nhớ để lộ các thành viên cho người dùng khung của bạn.
Đó là một chút hack, nhưng tôi thấy nó khá hữu ích.
Nguồn
2008-08-10 19:22:36