Comments on: Advanced mocking: anonymous test spy

By: Jimmy Bogard

Jimmy Bogard — Wed, 23 Apr 2008 13:55:41 +0000

@Steve

Thanks for the heads up on Constraints. I’ve found that my style of writing tests (BDD style) prohibits the use of constraints, though.

By: Steve Freeman

Steve Freeman — Wed, 23 Apr 2008 13:45:47 +0000

If you’re going to write about mocks, you should really understand the use of Constraints. They help you focus on the being precise about what matters about the message that one object sends another. I find that a lot of the tests I write have no closing assertions at all, because I’ve said everything in the Expectations.

I guess we need to make a point of writing up the concept more clearly.

By: Simone Busoli

Simone Busoli — Fri, 14 Mar 2008 13:44:15 +0000

Using the constraints syntax from Rhino you end up having little or no assertions between exercising and verification, you only set expectations. About issues, I think it mostly depends on how you feel comfortable with. I think that interaction-based testing takes a while to grab and could be harder to read, but once you’ve caught up with it even makes testing faster and requires less code. Actually, not always http://haacked.com/archive/2007/12/09/writing-unit-tests-for-controller-actions.aspx

BTW, I am always using NBehave for my tests right now, I love the SpecBase class, although I’m using it with NUnit since I prefer using the Resharper test runner which doesn’t have a plugin for NBehave yet. Anyways, guys, keep up the good work with NBehave!

By: Jimmy Bogard

Jimmy Bogard — Fri, 14 Mar 2008 13:15:16 +0000

@Simone

I’ve never used the constraints, thanks for bringing it up! Do you ever run into any issues related to assertions being alongside the expectations? I’ve never thought of using RhinoMocks to do my assertions as well as expectations. I guess I’m used to seeing “expectations, exercising, verification”.

By: Simone Busoli

Simone Busoli — Fri, 14 Mar 2008 12:54:38 +0000

Oh, with the new release of RhinoMocks you can even do this:

LastCall.Constraints(Property.AllPropertiesMatch(message));

so no need to override Equals.

By: Simone Busoli

Simone Busoli — Fri, 14 Mar 2008 12:35:09 +0000

I never used LastCall.Do a lot, but I see that in this case it requires you to write less code, though I tend to find the approach of setting constraints on the method to be more intuitive, like this:

var body = “Your order is ready!\r\nOrder #:” + order.OrderNumber;

var message = new MailMessage(“sender@email.com”, “recipient@email.com”, “Order processed”, body);

LastCall.IgnoreArguments().Constraints(Is.Matching(m => m.From.Address == message.From.Address && m.To.Count == 1));

Sure, if MailMessage overrides the Equals method it would be even easier:

LastCall.IgnoreArguments().Constraints(Is.Equal(message));

By: Baggio

Baggio — Thu, 13 Mar 2008 16:28:30 +0000

That helps. Thanks.

By: Jimmy Bogard

Jimmy Bogard — Thu, 13 Mar 2008 15:19:10 +0000

@Baggio

Quick note, Test Double is term that encapsulates any kind of alternate implementation created specifically for testing. The other terms are specific types of test doubles.

http://www.martinfowler.com/bliki/TestDouble.html

http://xunitpatterns.com/Test%20Double.html

http://martinfowler.com/articles/mocksArentStubs.html

I’ll follow up with some real-world examples.

By: Baggio

Baggio — Thu, 13 Mar 2008 13:16:46 +0000

As a TDD newbie, I can follow the examples but I find it difficult to grok and differentiate Test Spy, Test Doubles, Mocks, Stubs, Dummy object concepts.

By: Fredrik

Fredrik — Thu, 13 Mar 2008 13:06:52 +0000

@bogardj:

The fact that it’s generic is merely a convenience for accessing the mocked object through myMock.MockedInstance, which will then be typed instead of just an object. If you want type-safe expectations you need to buy a license for the professional edition of TypeMock, which includes the ‘natural mocks’ functionality.

By default any call to mocked objects are subverted, but you can control this (including for static/instance constructors). Also, you can use ExpectAndReturn and similar methods to make the mock behave like a stub.