在断言之前或之后模拟Verify/VerifyAll

Question

我已经习惯了在编写测试时遵循代码模式

public void TestMethod_Condition_Output()
{
    //Arrange----------------
    Mock<x> temp = new Mock<x>();
    temp.setup.......

    //Act--------------------
    classinstance.TestMethod()

   //Assert------------------

   temp.VerifyAll();
   Assert.AreNotEqual(.....)    
}

我习惯于在执行断言之前执行VerifyAll()。但最近在一些在线例子中，我看到人们先做断言，然后做VerifyAll，如果有的话。我确实觉得我的方式是正确的，除非我错过了什么。

如果我遗漏了什么，请通知我好吗？

Answer 1

在我看来，验证应该在断言之后。我希望断言靠近被测方法的调用，因为它们记录了该方法做了什么。模拟调用的验证详细说明了类如何使用它的依赖项。这对于直接绑定到方法本身是不太重要的。

从某种意义上说，对依赖关系的模仿变成了对实际测试本身的包装。这使得测试更容易理解(对我来说，至少是YMMV)。然后，我的测试遵循以下模式：

排列

• Mock
• Set up expected for dependencies
• Set up expected
• Create class测试下的创建类预期结果

行动

测试下的

• Invoke方法

断言

results

• Verify
• 断言实际结果与预期相符

我不知道我会不会对它学究，但这是对我来说最有意义的顺序。

Answer 2

在AAA风格的测试中，我不使用VerifyAll，而是使用显式调用的验证方法作为测试单元的一部分。在排列区域中，我只设置需要返回值的方法。

以Rhino为例。

//Arrange
mockedInterface.Stub(x => x.SomeMethod1()).Returns(2);

...

//Assert
mockedInterface.AssertWasCalled(x => x.SomeMethod1());
mockedInterface.AssertWasCalled(x => x.SomeMethod2());
Assert.AreEqual(...); // stanmdard NUnit asserttions

如果对SomeMethod2()的预期调用没有返回任何内容，那么我不需要设置它。

对于松散的模拟，实际上不需要调用VerifyAll，因为对其他方法的调用不会导致测试失败(除非需要返回，否则需要在Arrange部分中返回)。

断言的数量应该保持在最低限度(如果太大，则创建更多的测试)，并且它们的顺序也不应该真正重要。