2009-02-12 33 views
6

Tôi nghĩ rằng thực hành tốt là luôn trả về các danh sách hoặc mảng rỗng thay vì null khi phương thức không có kết quả để tránh kiểm tra null trong mã.Trả về các danh sách trống theo mặc định với Rhino Mocks

Vì Rhino Mocks trả về giá trị mặc định cho một đối tượng, không có danh sách và mảng, rất nhiều lần tôi phải thêm các kiểm tra rỗng vào hoặc thiết lập mocks với mong đợi trả về danh sách.

Có cách nào để định cấu hình hoặc mở rộng Rhino Mocks với hành vi này không?

var repositoryMock = MockRepository.GenerateMock<ICustomerRepository>(); 
IList<Customer> customers = repositoryMock.getCustomers(); 

Assert.IsNotNull(customers); 
Assert.AreEqual(0, customers.Count); 

Trả lời

0

Chỉ ra rằng hành vi này là có thể với Moq miễn là đối tượng trả về là IEnumerable. Các bài kiểm tra sau đây vượt qua:

[Test] 
public void EmptylListTest() 
{ 
    var repositoryMock = new Mock<ICustomerRepository>(); 

    IEnumerable<Customer> customers = repositoryMock.Object.GetCustomers(); 

    Assert.IsNotNull(customers); 
    Assert.AreEqual(0, customers.Count()); 
} 

[Test] 
public void EmptyArrayTest() 
{ 
    var repositoryMock = new Mock<ICustomerRepository>(); 

    Customer[] customerArray = repositoryMock.Object.GetCustomerArray(); 

    Assert.IsNotNull(customerArray); 
    Assert.AreEqual(0, customerArray.Length); 
} 

public interface ICustomerRepository 
{ 
    IEnumerable<Customer> GetCustomers(); 
    Customer[] GetCustomerArray(); 
} 
0

Không có gì trong Rhino Mocks để tự động khắc phục sự cố của bạn. Giải pháp đơn giản nhất là chỉ cần thiết lập một phương pháp mở rộng/tiện ích cho từng loại sử dụng SetupResult (hoặc repeat.any) để định cấu hình một giá trị mặc định.

Bạn luôn có thể khó khăn và liệt kê thông qua các thành viên, kiểm tra ILists/Arrays và thiết lập mocks động - tùy thuộc vào số lượng loại bạn có so với số lượng bạn có thể dành cho phương thức tiện ích này.

Chúc may mắn!

-1

Tôi nghĩ rằng việc thay đổi hành vi mặc định của các mocks để trả về các giá trị không mặc định sẽ là một động thái nguy hiểm.

Điều gì sẽ xảy ra nếu việc triển khai thực sự ICustomerRepository của bạn có lỗi trong đó để nó không trả về một danh sách trống và thay vào đó trả lại một giá trị rỗng?

Nếu bạn đã viết các bài kiểm tra đơn vị khác và được thử nghiệm dựa trên phiên bản giả của ICustomerRepository tự động trả về danh sách trống thì bạn sẽ nghĩ rằng mọi thứ đều OK. Bạn thậm chí có thể xây dựng mã đó và nghĩ rằng nó sẽ hoạt động đúng cách, vì vậy bạn chạy ứng dụng đã biên dịch của mình và nó bắt đầu bị lỗi.

Tại sao? Bởi vì các lớp của bạn nhấn ICustomerRepository không xử lý đúng các giá trị rỗng.

Tôi sẽ khá rõ ràng và đặt kỳ vọng trong thử nghiệm để trả về một IList trống từ phương thức getCustomers() hơn là có điều gì đó "ma thuật" xảy ra bên trong mô hình. Tại sao? Bởi vì nó cải thiện khả năng đọc và mã hoạt động theo những gì các nhà phát triển khác có thể không quá quen thuộc với tê giác sẽ mong đợi nó hoạt động. tức là phương thức không có kỳ vọng trả về giá trị mặc định.

+1

Đó là điểm hợp lệ mà ứng dụng sẽ sụp đổ nếu ICustomerRepository trả về null, nhưng đó là lỗi với kho lưu trữ, chứ không phải các lớp sử dụng. Tôi sẽ (hy vọng :)) có các bài kiểm tra đơn vị cho kho lưu trữ để nắm bắt vấn đề đó. – Dala

+0

Tôi có thể sống với một mô hình phép thuật nhiều hơn bình thường :). Tôi muốn họ hành động nhiều như phần còn lại của hệ thống ra khỏi hộp. Cảm ơn các đầu vào! – Dala

Các vấn đề liên quan