我不知道它是做什么用的Mock.Verifiable(),如果我理解正确的话,下面的代码:
var mockContainer = new Mock<CloudBlobContainer>(MockBehavior.Strict, StorageUri);
mockContainer.Setup(c => c.GetBlockBlobReference(It.IsAny<string>()))
.Returns(mockBlobItem.Object);
// ...
mockContainer.Verify(c => c.GetBlockBlobReference(It.IsAny<string>()), Times.AtLeastOnce);
这将等同于:
var mockContainer = new Mock<CloudBlobContainer>(MockBehavior.Strict, StorageUri);
mockContainer.Setup(c => c.GetBlockBlobReference(It.IsAny<string>()))
.Returns(mockBlobItem.Object)
.Verifiable();
// ...
mockContainer.Verify();
还有第三种选择:
var mockContainer = new Mock<CloudBlobContainer>(MockBehavior.Strict, StorageUri);
mockContainer.Setup(c => c.GetBlockBlobReference(It.IsAny<string>()))
.Returns(mockBlobItem.Object);
// ...
mockContainer.Verify();
我研究了很多例子,因此通常使用第二个或第三个选项。还有.VerifyAll().
- 它是如何正确的,为什么?
- 有什么特点和陷阱?
- 这些选项如何依赖于Strict和Loose行为?
我找不到Moq的文档(除了这个有缺陷的文档),它还在吗?
是的,你没看错。
从文章中可以判断,在调用Setup中定义的方法之前,可以使用这个方法来检查调用。
此外,根据英文答案,建议不要使用这种方法。它显然与AAA模式相矛盾。矛盾在于,用于测试的数据准备(Arrange)和应该测试什么的描述(Assert)发生在Setup方法中。
项目维护者自己提出了更多关于为什么不值得继续开发这样一个 API 的案例
但是,这种方法可以证明是合理的,例如,需要避免代码重复。
唯一不能使用这种方法的情况是需要检查调用次数。在这种情况下,您只能使用带有预期调用的完整描述的Verify方法:
关于使用不带参数的验证。它只会检查您在设置中使用 Verifiable 方法标记的方法:
如果要检查是否调用了尚未标记为Verifiable的方法,可以使用VerifyAll方法:
但就个人而言,我不会使用VerifyAll,因为它一点也不明显。
开发是在 github 上进行的,除了您提到的详细文档之外,还有一个快速入门和使用示例。