AAA - StrictMock request

8 views
Skip to first unread message

Peter Morris

unread,
Apr 14, 2009, 10:48:19 AM4/14/09
to Rhino.Mocks
I noticed today that MockRepository.GenerateMock uses DynamicMock
internally. I really like not having to create an instance of
MockRepository myself but sometimes I really want to use a StrictMock.

For example.

var a = new Document { Published = false};
var b = new Document { Published = true};
var c = new Document { Published = false};

var documents = new List<Document>();
documents.Add(a);
documents.Add(b);
documents.Add(c);

var mockPublishService = MockRepository.GenerateMock<IPublishService>
();
mockPublishService.Expect(x => x.Publish(a));
mockPublishService.Expect(x => x.Publish(c));

var testSubject = new SomeClass(mockPublishService);
SomeClass.DoSomethingWhichPublishesDocuments(documents);

mockPublishService.VerifyAllExpectations();


This passes because Publish(a) and Publish(c) are called, but I want
to use a StrictMock because I am also asserting that *only* "a" and
"b" are Published and not "c".

Could we please have a static MockRepository.GenerateStrictMock<T>
method?

Tim Barcz

unread,
Apr 14, 2009, 11:01:52 AM4/14/09
to Rhino...@googlegroups.com
I hope others post on this, but I'll chime in:

I think it was an explicit decision not to include StrictMock() in the syntax as the use of strict mocks is generally frowned upon as it can lead to over specification of tests.

(With the source available to you, you can always add this method in your own code base whether or not this gets voted up or down.)

Peter Morris

unread,
Apr 14, 2009, 11:13:21 AM4/14/09
to Rhino...@googlegroups.com
> I think it was an explicit decision not to include StrictMock() in the
> syntax as the use of strict mocks is generally frowned upon as it can lead
> to over specification of tests.

Which I understand fully, however, sometimes you want to test that ONLY
certain things happen and the static methods are a really nice way of
reducing lines of code written in tests.


> (With the source available to you, you can always add this method in your
> own code base whether or not this gets voted up or down.)

:-)

I don't like having my own variation of someone else's project, and if the
change was voted down I would have to choose between that and changing my
tests.


Pete
====
http://mrpmorris.blogspot.com
http://www.AlterEgos.com - Who do you want to be?

Tim Barcz

unread,
Apr 14, 2009, 11:25:08 AM4/14/09
to Rhino...@googlegroups.com
Which I understand fully, however, sometimes you want to test that ONLY
certain things happen and the static methods are a really nice way of
reducing lines of code written in tests.

While I understand the need/desire for strict mocks (believe me I do).  You can do assertions that something is never called on a dynamic mock which gives you similar behavior.

Peter Morris

unread,
Apr 14, 2009, 11:33:13 AM4/14/09
to Rhino...@googlegroups.com
> While I understand the need/desire for strict mocks (believe me I do).
> You
> can do assertions that something is never called on a dynamic mock which
> gives you similar behavior.

By using .Throw or some other technique?

Tim Barcz

unread,
Apr 14, 2009, 11:37:45 AM4/14/09
to Rhino...@googlegroups.com
Take a look at Repeat.Never()

Unless someone has some additional strong objections to this, I would be okay with adding this.  (Note to others, chime in now if you want your voice heard)

Tim

Alex McMahon

unread,
Apr 15, 2009, 3:49:05 AM4/15/09
to Rhino...@googlegroups.com
I think that it should not be added, for the same reasons given already; I think it's much better to have a smaller API surface, and one that encourages best practice. Also it's worth noting that you can use AssertWasNotCalled(), which gets much closer to what you really want; In your example you said that you wanted a and b to be called and not c, therefore I'd say it's better to specify these on a granular level rather than only a and b can be called; what happens when you add method d that has no side-effects and costs nothing to call, why would you want the test to fail if d is called?

Jim

unread,
May 19, 2009, 3:14:37 PM5/19/09
to Rhino.Mocks
I haven't used Repeat.Never, that seems like a good approach, but you
can also use AssertWasNotCalled() which I think is nice because it
makes it very clear what you are trying to test.
> >http://www.AlterEgos.com- Who do you want to be?- Hide quoted text -
>
> - Show quoted text -
Reply all
Reply to author
Forward
0 new messages