AtMost obsolete in v4

[RizThon]

Hi,

I'm using Moq v4.

I have a strict Mock, with a few setup methods that should be called only once. At the end I do a VerifyAll().

            Mock<IFoo> fooMock = new Mock<IFoo>(MockBehavior.Strict);

            // Mocks some methods.
            fooMock.Setup(xxx).Returns(10).Verifiable();
            ...

            // Verifies that all my methods were called.
            mockRepository.VerifyAll();

If I want to check that all my methods were only called once, I could add

            fooMock.Setup(xxx).Returns(10).AtMost(1).Verifiable();

but AtMost is obsolete, and the comment says I'm supposed to use Verify(Times.AtMost(x)).

So looks like I have to specifically call the verify for all my methods

            fooMock.Verify(xxx, Times.Once);
            ...

instead of simply calling VerifyAll once.

I feel that being able to specify Times at setup time is quite convenient when using VerifyAll. Am I missing something?

Thanks.

[Daniel Cazzulino]

The recommended approach is to use a AAA-style for tests, where you have separated Arrange (setups), Act (invoke) and Assert (Verify). 

This way, you know exactly what you're verifying and it's co-located with the other unit test Asserts.

I seldom use strict mocks. Most of the time, I just care about verifying one or two interactions per test, and don't care about the rest of the interactions.

/kzu

--
Daniel Cazzulino | Developer Lead | XML MVP | Clarius Consulting | +1 425.329.3471

--
Post: moq...@googlegroups.com
Unsubscribe: moqdisc-u...@googlegroups.com

[Daniel Cazzulino]

Strict mocks are a smell in general. They make your tests brittle for little gain.

Feel free to send a PR to add Times at the end of a setup. I'd merge it anyways for consistency.

On Thu, Jul 23, 2015 at 5:59 AM Alex K <akub...@gmail.com> wrote:

I disagree because for the "real mock" in the test I have to use Strict Mock(here're some confusion because of in Moq there're no such thing as a Stub. For the stub I have to use Loose Mock). When I'm calling VerifyAll I'm verifying that all "setups" which were set in "Arrange" part were actually done in the Act part when we performed certain call on a SUT(System under the test). I don't see anything bad here, except the thing you have said "it is not obvious what actually is checked", but the main problem I see 

if I want to verify that something was really called I have to repeat in the "Assert" part all the "Setups" I did for that mock object in the "Arrange" part. I see problems with DRY principle.

I see that my "Arrange" part will have just setups for that mock, and "Assert" part will have Verify call(s) with the same lambda(s) and additional Times argument. May be I'm doing something wrong? If yes, please tell me how to avoid those repetitions?

Don't suggest me use Loose mock for the "mock"(I mean real mock, not a stub). In that scenario I'm not able to check that nothing was called what should not be called.

[Alex K]

I disagree because for the "real mock" in the test I have to use Strict Mock(here're some confusion because of in Moq there're no such thing as a Stub. For the stub I have to use Loose Mock). When I'm calling VerifyAll I'm verifying that all "setups" which were set in "Arrange" part were actually done in the Act part when we performed certain call on a SUT(System under the test). I don't see anything bad here, except the thing you have said "it is not obvious what actually is checked", but the main problem I see 

if I want to verify that something was really called I have to repeat in the "Assert" part all the "Setups" I did for that mock object in the "Arrange" part. I see problems with DRY principle.

I see that my "Arrange" part will have just setups for that mock, and "Assert" part will have Verify call(s) with the same lambda(s) and additional Times argument. May be I'm doing something wrong? If yes, please tell me how to avoid those repetitions?

Don't suggest me use Loose mock for the "mock"(I mean real mock, not a stub). In that scenario I'm not able to check that nothing was called what should not be called.

On Thursday, 21 October 2010 00:41:37 UTC+11, danielkzu wrote: