Mock Verify/VerifyAll before or after Assertion

I have been used to following code pattern while writing my test

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

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

开发者_运维问答   //Assert------------------

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

I have been used to do the VerifyAll() before performing Assertions. But lately on some online examples, I have seen people doing Assertion first and then VerifyAll, if any. I do feel that my way is the correct way unless I am missing something.

Could you please alert me if I am missing anything.

In my opinion, the verify should come after the asserts. I want the asserts close to the invocation of the method under test as they are documenting what the method does. The verifications of the mock invocations are detailing how the class uses it's dependencies. This is less important to tie directly to the method itself.

In a sense the mocking of the dependencies becomes a wrapper around the actual test itself. This makes the test more understandable (to me, anyway, YMMV). My tests then follow this pattern:

Arrange

• Mock
• Set up expectations for dependencies
• Set up expected results
• Create class under test

Act

• Invoke method under test

Assert

• Assert actual results match expected results
• Verify that expectations were met

I don't know that I would be pedantic about it, but this is the order that makes the most sense to me.

In a AAA style testing I do not use VerifyAll but rather than verify methods were called explicitly as part of the unit of test. Within the Arrange area I only setup methods that need to return a value.

using Rhino as an example...

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

...

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

I do not need to setup the expected call to SomeMethod2() if it does not return anything.

With Loose mocks there is no real need to call VerifyAll as calls to other methods would not fail the test (unless a return is needed then it is required in the Arrange section).

The amount of assertions should be kept to a minimum (create more tests if it gets too large) and the order of them should not really matter either.