我覺得你應該返回第一個或默認的客戶:
mock.Setup(m => m.GetById(IsAny<int>())).Returns<int>(
id =>
customersRepo.FirstOrDefault(c => c.Id == id)
);
也請記住,你並不需要在嘲笑重新實現資源庫的邏輯(即怪異非常脆弱)。這是模擬。你可以嘲笑任何你想要的結果,沒有任何邏輯:
mock.Setup(m => m.GetById(42)).Returns<int>(new Customer { Id = 42 });
使用嘲笑驗證互動 - 即你的資料庫被稱爲預計法預計參數的客戶。
如果你想測試一些服務的業務邏輯,那麼服務是一個被測系統(SUT),你不應該嘲笑它。但是,如果你的服務同時具有業務邏輯和數據訪問邏輯,那麼它做的事情太多了。提取數據訪問邏輯一些倉庫類,它將實現接口:
public interface ICustomerRepository
{
Customer GetById(int id);
// other methods related to customr data access
}
然後,讓你的服務依賴於該接口上(依賴倒置):
public class YourService
{
private readonly ICustomerRepository _repository;
// dependency injection
public YourService(ICustomerRepository repository)
{
_repository = repository;
}
public void ExecuteSomeBusinessLogic()
{
// your code will go here
}
}
然後寫服務的測試。因此,服務需要依賴性(客戶存儲庫),你應該嘲笑這種依賴性。並按照您的預期驗證服務與依賴關係進行交互。例如。在ExecuteSomeBusinessLogic測試中,我們應該檢查該服務會詢問顧客,ID爲42(是的,怪異的業務邏輯):
[Test]
public void ShouldPerformGoodStuffWhenCustomerFound()
{
// Arrange
var mockRepository = new Mock<ICustomerRepository>();
mockRepository.Setup(r => r.GetById(42)).Returns(new Customer { Id = 42 });
var service = new YourService(mockRepository.Object);
// Act
service.ExecuteSomeBusinessLogic();
// Assert
mockRepository.VerifyAll();
// check other stuff
}
如果你寫的情況下測試時,沒有在數據庫中找到自定義,只安裝不同的回報:
mockRepository.Setup(r => r.GetById(42)).Returns(null);
我不能相信這些設置按預期工作。這兩個設置都返回一個'IEnumerable',但一個表示它返回一個'string',另一個表示它返回一個'int'。這兩者都不是'IEnumerable '。 –