Question

我在编写测试时习惯了以下代码模式

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

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

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

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

在执行断言之前，我已经习惯了执行VerifyAll（）。但最近在一些在线示例中，我看到人们先做Assertion，然后是VerifyAll，如果有的话。我觉得我的方式是正确的，除非我遗漏了什么。

如果我遗失任何东西，请你提醒我。

Answer 1

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

从某种意义上说，依赖项的模拟成为实际测试本身的包装器。这使得测试更容易理解（对我来说，无论如何，YMMV）。然后我的测试遵循这种模式：

安排

模拟
设置对依赖项的期望
设置预期结果
创建测试中的课程

法

调用测试方法

断言

断言实际结果与预期结果相符
验证是否符合预期

我不知道我会对此迂腐，但这是对我最有意义的顺序。

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，因为对其他方法的调用不会使测试失败（除非需要返回，然后在编配部分中需要返回）。

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

在断言之前或之后模拟验证/验证

2 个答案: