Moq
Posts related to the Moq mocking framework
Last time I announced Linq to Mocks, some said Moq didn't actually have anything to do with Linq. Despite the heavy usage of lambda expressions and expression trees, the "q" in Linq is for "query" after all. And they were right, of course, but it was fun anyway, and the name is definitely cool IMO :).
But this time around, I'm happy to say that it's finally true. What the next version of Moq (early beta readily available now) allows you to express in a very declarative way essentially is:
from the universe of mocks, get me those that behave like this
(thanks Fernando Simonazzi for coming up with this phrase :))
Rather than procedurally defining how the mock will behave, its specification is part of the query:
ControllerContext controllerContext =
(from context in Mocks.Query<ControllerContext>()
where context.HttpContext.User.Identity.Name == "kzu" &&
context.HttpContext.Request.IsAuthenticated == true &&
context.HttpContext.Request.Url == new Uri("http://moq.me") &&
context.HttpContext.Response.ContentType == "application/xml"
select context)
.First();
A few things to notice:
- The query returns an infinite list of mocks that behave according to the specification/query. You typically get the first of such list.
- The resulting objects are of the actual mocked type, not Mock<T>, so there's no need to do controllerContext.Object anymore. The reasoning for that is that typically you would be able to fully setup the mock in the query, hence there'd be no need to get the Mock<T> back, unlike new Mock<T> where you do need to set it up.
- Fluent mocking happens automatically within the query. And even better, you're NOT limited to just property accesses. *Anything* that is a valid Setup on a mock can appear anywhere in the fluent mock traversal (i.e. context.HttpContext.GetSection("server") == configuration)
- You can have multiple mocks within the query and set them all up together.
- If you want to access these multiple mocks afterwards, you can just return all of them using an anonymous type projection (select new { Context = context, Configuration = configuration } ).
Here's a more comprehensive example of setting up two mocks at the same time:
ControllerContext controllerContext =
(from context in Mocks.Query<ControllerContext>()
from configuration in Mocks.Query<ServerSection>()
where context.HttpContext.User.Identity.Name == userName &&
context.HttpContext.Request.IsAuthenticated == true &&
context.HttpContext.Request.Url == new Uri("http://moq.me") &&
context.HttpContext.Response.ContentType == "application/xml" &&
context.HttpContext.GetSection("server") == configuration &&
configuration.Server.ServerUrl == new Uri("http://moq.me/api")
select context)
.First();
Finally, if you needed to access both the context as well as the configuration from the results of this query, you could do:
var mocks =
(from context in Mocks.Query<ControllerContext>()
from configuration in Mocks.Query<ServerSection>()
where context.HttpContext.User.Identity.Name == userName &&
context.HttpContext.Request.IsAuthenticated == true &&
context.HttpContext.Request.Url == new Uri("http://moq.me") &&
context.HttpContext.Response.ContentType == "application/xml" &&
context.HttpContext.GetSection("server") == configuration &&
configuration.Server.ServerUrl == new Uri("http://moq.me/api")
select new { Context = context, Configuration = configuration }))
.First();
MyController controller = new MyController { ControllerContext = mocks.Context };
// Do something with the configuration object...
ServerSection config = mocks.Configuration;
Next question would be how to setup exceptions to be thrown, and how to verify? You just use the existing Mock.Get functionality:
Mock.Get(controllerContext).Setup(...)
// or verify
Mock.Get(controllerContext).Verify(...);
Just for the sake of comparison, the equivalent "procedural" code to setup the same mock shown in the complete example above, you'd currently do:
var context = new Mock<ControllerContext>();
var configuration = new Mock<ServerSection>();
context.SetupGet(c => c.HttpContext.User.Identity.Name).Returns(userName);
context.SetupGet(c => c.HttpContext.Request.IsAuthenticated).Returns(true);
context.SetupGet(c => c.HttpContext.Request.Url).Returns(new Uri("http://moq/me"));
context.SetupGet(c => c.HttpContext.Response.ContentType).Returns("application/xml");
context.SetupGet(c => c.HttpContext.User.Identity.Name).Returns(userName);
context.Setup(c => c.HttpContext.GetSection("server")).Returns(configuration);
configuration.Setup(c => c.Server.ServerUrl).Returns(new Uri("http://moq.me/api"));
Yes, the query version has one more line of code, the .First() call. Yes, it's gonna be largely a matter of personal style and preference, just like many prefer invoking .Where(…) and .Select(…) instead of from…where…select.
Choice is good in this case, IMO.
There are many more features in this upcoming version of Moq. I'll try to blog about those too before/after we ship :). But this is my favorite!
Go get it!
In my very recent previous post I said "mocking and stubbing easier than ever", but actually forgot to mention the stubbing part :S.
This one is not new for users of moq-contrib, but we decided to move this to the core Moq library as we get the question on how to stub properties often enough... :)
It's actually rather simple and easy to implement just by using Moq external API, but as a facility, here's what you can do:
var mock = new Mock<IHaveValue>();
// start "tracking" sets/gets to this property
mock.Stub(v => v.Value);
// alternatively, provide a default value for the stubbed property
mock.Stub(v => v.Value, 5);
// Now you can do:
IHaveValue hv = mock.Object;
// Initial value was stored
Assert.Equal(5, hv.Value);
// New value set which changes the initial value
hv.Value = 6;
Assert.Equal(6, hv.Value);
What is new in this version beyond the original moq-contrib stubbing, is the ability to stub all properties of the object in a single call:
var mock = new Mock<IFoo>();
mock.StubAll();
This feature integrates seamlessly with the default value behavior specified for the mock, as explained in the previous post, meaning that you can stub all properties and cause them to return new mocks when appropriate, also recursively (but lazily!), in a single call. This may be redundant to note, but it's just to point that the API and behavior is still consistent.
If you want to have some fun reading rather crazy reflection API usage to invoke various generic methods including ones receiving Func<T> and passing function pointers with it, go ahead. It was FUN :).
Next: out/ref parameters in Moq!!!
I've just released a new version of Moq which contains a few bug fixes but two extremely useful features: recursive mocks and mocked default values.
Recursive mocks
Quite often you have a root mock object from which other mocks should "hang" through property accesses, such as HttpContextBase.Response: you want the response object returned to also be a mock.
Setting such hierarchies before this release was quite verbose:
var context = new Mock<HttpContextBase>();
var response = new Mock<HttpResponseBase>();
context.Expect(c => c.Response).Returns(response.Object);
response.Expect(r => r.ContentType).Returns("application/xml");
In this new release, it's possible to just use your root object to set expectations on any path in the hierarchy, so the above turns to:
var context = new Mock<HttpContextBase>();
context.Expect(c => c.Response.ContentType).Returns("application/xml");
The auto-mocked properties have the same behavior as the "owning" mock.
I've found this extremely useful and right now it's also supported in TypeMock and soon (I hope) followed by Rhino too.
Mocked default values
In Moq, your mocks are by default "loose", so they never throw exceptions when they are invoked without a corresponding expectation. Most people find this very intuitive as a default, but sometimes wish some properties returned mocks instead. In spirit, this is similar to recursive mocks, but it's more of a lazy-on-demand creation of mocks as needed, without the need to set expectations on anyone.
Following the example above, you could create the context like so (note the added property to set the default value behavior):
var context = new Mock<HttpContextBase> { DefaultValue = DefaultValue.Mock };
var response = context.Response; // will be non-null, an auto-generated mock!
// I could set further expectations on this object, by retrieving its corresponding Mock
Mock.Get(response).Expect(r => r.ContentType).Returns("application/xml");
The setting is recursive, so if I request a property from the response mock that is also of a mock-able type, I'd get a mock too.
Both are closely related, and maybe they could both be called "recursive mocks" if you will.
One of the coolest things in Moq (IMO) continues to be the transparent continuum between fake/stub/mock which basically depends on how you use the one and only "moq" :).
On top of that, I got a really cool domain name for the project: http://moq.me
Feedback welcomed on both features! Next I have to write about future directions...
I've argued in the past that this theoretical discussion is utterly useless. In my experience you need slightly different things from your test doubles at different times and depending on the scenarios and what you care about testing in a particular test.
If you're not using any mock/stub framework, you're typically creating manual test aids that morph (so that you can reuse them) as your tests evolve, and end up encompassing a mixture of a fake (i.e. you might put in an in-memory implementation), a stub (flags to tell you whether given members were called) and a mock (you might provide delegates to execute when members are executed, so that you can throw/callback/whatever). I've done this countless times before jumping to a framework/library to help me with this, and I know this is the continuum most developers live in.
Yet, we still see discussions like Rhino Mocks 3.5 Design Decisions: The role of Stub vs. Mock, were the user is asked to make a choice that he will seldom understand without reading the theoretical background. This is counter-productive IMO.
Compare the original two versions with Moq's version:
public void When_user_forgot_password_should_save_user()
{
var userRepository = new Mock<IUserRepository>();
var smsSender = new Mock<ISmsSender>();
var theUser = new User { HashedPassword = "this is not hashed password" };
userRepository.Expect(x => x.GetUserByName("ayende")).Returns(theUser);
var controllerUnderTest = new LoginController(userRepository.Object, smsSender.Object);
controllerUnderTest.ForgotMyPassword("ayende");
userRepository.Verify(x => x.Save(theUser));
}
As you see, the way you use the "mock" is what makes it look more like a stub or a "true" mock (i.e. you verify all expectations, and you create it with MockBehavior.Strict). You don't have to pick a Stub vs Mock.
This simplifies the learning curve on the framework, and basically allows you to set intuitive options that don't force you entirely in one way or the other (the combination of Expect...Verifiable...Verify allows for VERY flexible usage).
I hope just like everyone's now seeing the value of NOT having an explicit record-reply model, we'll move past this rigid theoretical frame and into a more pragmatic and flexible view of mocking in general.
If you're familiar with Moq, you know that it relies on lambda expressions heavily. This is very good as you get full support from intellisense and refactoring features in Visual Studio. However, it also means you're for the most part restricted to setting expectations on things that your code has access too (public or internal members).
This is especially annoying with protected members, which are very common in template method pattern, factory methods, etc. In this case, you can't simply set an expectation with a lambda expression, as you have no access from the "outside" to the protected member. Being an important scenario, though, we wanted to add support for it.
We could have just extend the core Mock<T> API and add loosely-typed members that received strings (i.e. mock.Expect("Foo")). This would have been bad from the guidance point of view, as it would make for an easy path to "hell" for people not familiar with lambda expression ("mmm... I could use this overload with that lambda thinghy, or just use the simpler string-based overload..."). We'd much rather keep people using strong-typed, lambda-based expectations rather than jumping at the ease of strings.
So, we reached a compromise: we implemented protected expectations using strings, but it will only work for non-public members :). We also didn't want to make this functionality too easy to discover, so we expose it as an extension method that you enable by importing the Moq.Protected namespace:
using Moq.Protected;
then you use the Protected "extension point":
var mock = new Mock<CommandBase>();
mock.Protected()
.Expect<int>("Execute")
.Returns(5);
The Expect overload receiving a type parameter specifies the return value from the invocation. You also have ExpectGet/Set members, which expose the same functionality of the strong-typed lambda versions.
Note how rather than polluting the main API with extension overloads receiving strings, we hang all members from the IProtectedMock returned from the Protected() method call. That's an interesting use of extension methods I think, which you also get to see quite a lot in newer C# 3.5 libraries such as Autofac and Umbrella.
Another difference in the invocation style for expectations is the argument matching. Here, I couldn't find an easier way to specify then than using a separate class, ItExpr to specify them:
mock.Protected()
.Expect<string>("Execute",
ItExpr.IsAny<string>())
.Returns(true);
The need for this is subtle, and lies in the fact that the Expect method is not receiving a lambda expression, unlike the strong-typed version, and the alternatives were far worse. So basically ItExpr is an expression-returning version of the It class. I still haven't figured out how you would use custom matchers in this scenario. I guess it would involve building the expression trees just like we do to reconstruct the same expression that would result from using the matcher in the lambda Expect.
If you want to play with it, just go ahead and get the latest version from Google Code.
Don't forget to give us feedback through the discussion list or issue tracker.
Enjoy!
Today we shipped Moq v2.5. It's been a while since RC1 (a month or so feels so long for an open source agile project!) and we god very good feedback and suggestions for the final release. I'm pretty happy with the current drop and felt it was time for a new stable release.
The change log is quite extensive and yet there are quite a few fixes and improvements here and there that are not reflected in it. Over the next few posts I'll be showcasing the various new features. For now, here's the log:
Version 2.5
- Added support for mocking protected members
- Added new way of extending argument matchers which is now very straightforward
- Added support for mocking events
- Added support for firing events from expectations
- Removed usage of MBROs which caused inconsistencies in mocking features
- Added ExpectGet and ExpectSet to better support properties, and provide better intellisense.
- Added verification with expressions, which better supports Arrange-Act-Assert testing model (can do Verify(m => m.Do(...)))
- Added Throws<TException>
- Added mock.CallBase property to specify whether the virtual members base implementation should be called
- Added support for implementing, setting expectations and verifying additional interfaces in the mock, via the new mock.As<TInterface>() method (thanks Fernando Simonazzi!)
- Improved argument type matching for Is/IsAny (thanks Jeremy.Skinner!)
My personal favorites: streamlined custom matchers (you can completely replace the built-in It.IsXXX matchers), mocking events and adding interfaces to a mock (I'll expand on those soon).
Go ahead and get the latest version from Google Code.
As usual, we'd love to hear your feedback at the discussion list or issue tracker, and patches are always welcome :)
WCF is the second biggest framework after ASP.NET that sooner or later forces you to use a static "context" property to do anything beyond the trivial stuff. ASP.NET has the HttpContext.Current, whereas WCF has the WebOperationContext.Current for example.
My friend Pablo Cibraro proves how you can quite easily make your implementations that depend on such static contexts testable without resorting to black-magic voodoo TypeMock kind of stuff. Any .NET developer can trivially introduce an indirection to make their classes testable, even if they depend on static classes.
So, don't buy a product just because you're lazy and want to avoid creating a few wrapper classes and interfaces. Most of them can be copied directly from Reflector's API rendering. And once you have the interfaces, you can just use MoQ or Rhino (or whichever mock framework you like) to mock them any way you want.
Always use the simplest thing that could possibly work.
Update: added a reference to other mock frameworks that can be used to the same effect. Apparently some people get picky if you have a preference and it happens to be the one you built :)
Update II: For those that didn't follow the discussion over at
Roy's blog, I'll
repeat an analogy that better explains what my point was with
my previous post on mocking statics:
If you are not careful enough and can shoot yourself in the foot, the less shotguns you have around the house, the better.
That said, you may have a big, ugly, old contender where you really need the biggest shotgun you can get. But you'll be giving it to your very best guys, not to the newbie soldier.
Better to teach the newbies how to shoot smaller objectives with a regular pistol first (the whole point of Pablo's post on mocking WCF static context).
Some may say this sounds somewhat paternalist. I think that's pragmatism.
I'd rather show developers how to work around statics imposed by some "legacy" framework they happen to use (i.e. WCF and ASP.NET static contexts) by using typical OO techniques such as the one explained by Pablo, than giving them a bazooka and spending endless hours explaining how to NOT overuse it.
For the record, the technique is *exactly* the same used the ASP.NET MVC team, I don't hear anyone calling HttpContextBase and friends "utterly useless wrappers". I find it hard to think about a case where such a technique could not be applied to make new code written to interact/integrate with a legacy system testable. Would love to find a counter example.
Sometimes it's just that the solution ends up being much simpler than you initially thought. How hard do you think it is to do the ASP.NET MVC trick for the ASP.NET HttpContext? Go get the sources, find class MvcHandler and see for yourself.
Also, Pablo clarified that his original post was how to mock the WCF context, regardless of its static nature (as you could still pass it to your implementation's constructor), when it's neither an interface, nor a class with any virtuals that enable easy mocking.
More to the case against statics and singletons at Scott's blog.
Today, the MoQAPI lets you setup expectations and later verify them, like so:
[Fact]
public void FillingRemovesInventoryIfInStock()
{
//arrange/setup
var order = new Order(TALISKER, 50);
var mock = new Mock<IWarehouse>();
//setup - expectations
mock.Expect(x => x.HasInventory(TALISKER, 50)).Returns(true);
//act
order.Fill(mock.Object);
//assert
Assert.True(order.IsFilled);
//verify interaction
mock.VerifyAll();
}
A very good feedback I got during the past MVP Summit was that the current approach moves all the semantic relevance for mocks up to the setup phase of the test. In order words, it doesn't fit well in the Arrange-Act-Assert pattern, as effectively the "asserts" (expectations that must be met) are now in the "arrange" (or setup) phase of the test.
The Verify/VerifyAll call which is down at the assertion phase contains no semantic whatsoever about what it is you are expecting to happen.
In order to be accomodate this requirement, I'm gonna be adding a overload to Verify that takes the expression you want to verify:
//assert
mock.Verify(x => x.HasInventory(TALISKER, 50));
This would bring back the assertion phase to the place it belongs, if that's what you need. And because the default behavior on MoQ mocks is that they never throw on unexpected invocations, you can use the Expect only to setup return values when you need them (I'm hesitant to rename Expect to Setup, as for people using strict mocks that prefer the VerifyAll approach, it won't make much sense).
What do you think?
I wrote before about What's wrong with the Record/Reply/Verify model for mocking frameworks, and in that context, why Moq didn't provide a mock verification functionality.
Given that the project is driven by users' feedback, both internal (our own team who's using it extensively) and external, we added mock verification to Moq. I guess this finally settles the issue of whether it's a mocking framework or a stub framework :).
Verification
So let's review how this feature is used and a couple alternatives that are in place:
//setup - data
var order = new Order(TALISKER, 50);
var mock = new Mock<IWarehouse>(MockBehavior.Relaxed);
//setup - expectations
mock.Expect(x => x.HasInventory(TALISKER, 50)).Returns(true);
...
// other test code, exercising the mock
...
//verify state
Assert.IsTrue(order.IsFilled);
//verify interaction
mock.VerifyAll();
The new VerifyAll() method will ensure all expectations are satisfied (invoked). There's also a Verify() alternative which is more flexible, allowing you to verify only those expectations that have been marked as Verifiable:
//setup - expectations
mock.Expect(x => x.HasInventory(TALISKER, 50)).Verifiable().Returns(true);
//setup other expectation that may not be Verifiable
...
//verify only Verifiable expectations.
mock.Verify();
This alternative is especially useful when you're setting up optional default expectations in a fixture setup and verifying at tear down:
Mock<IWarehouse> warehouseMock;
[SetUp]
public void SetUp()
{
warehouseMock = new Mock<IWarehouse>(MockBehavior.Loose);
// setup default non-verifiable (optional) expectation/return value
warehouseMock.Expect(warehouse => warehouse.HasInventory(TALISKER, 50)).Returns(true);
}
[TearDown]
public void TearDown()
{
warehouseMock.Verify();
}
Reusing default expectations in fixture setups makes for much more compact and targeted mock setups in specific tests. All the boring default (maybe optional) interactions are moved away to the setup. In my experience (and that of some of our users) this makes for much cleaner tests.
This can also be combined with the ability to override expectations. So in the example above, if a particular test needs to return a different value, it can just re-set the expectation and the new expectation will be the active one:
// override default expectation set in fixture setup
warehouseMock.Expect(warehouse => warehouse.HasInventory(TALISKER, 50)).Returns(false);
Consistency via MockFactory
After some very good feedback and a bit of back-and-forth with Garry over at Hanselforum, we finally settled on a way to make mock creation and verification easier when multiple mocks are in use in a single test.
If you're using a mock behavior other than the default (i.e. you want strict mocks that will throw for anything without an explicit expectation, or the absolute opposite, a loose mock) you'll be passing this enumeration value to each and every mock you create:
//setup - data
var warehouseMock = new Mock<IWarehouse>(MockBehavior.Loose);
var loggerMock = new Mock<ILogger>(MockBehavior.Loose);
//other mocks with same behavior
If your mocks always have the same behavior, and you use a particular style of verification always (Verify or VerifyAll as explained above), you can save some boring typing and gain consistency by using a MockFactory. This factory can be initialized at fixture setup and used on tear down to verify all mocks created using its Create method:
MockFactory factory;
[SetUp]
public void SetUp()
{
factory = new MockFactory(MockBehavior.Loose);
}
[TearDown]
public void TearDown()
{
factory.Verify();
}
[Test]
public void ShouldDoSomething()
{
//...
var mock = factory.Create<IWarehouse>();
//...
// all created mocks will be verified automatically
// when the test finishes
}
This feature further reduces code duplication and makes tests even more concise. The explicit nature of expectations and verification makes it unnecessary to (ab)use the disposable pattern which precludes fixture setup/teardown reuse.
We continue to strive to keep Moq faithful to its core design principle of simplicity by allowing manipulation of mock instances directly. Most mocking newcomers to will find this a refreshing alternative to the established and somewhat unnatural (I'd say also artificial) record/reply model.
Let us know what you'd like to see in future versions, what you like and what you don't! You can either submit an issue (not only bugs, but also suggestions) or send an email to the user's group.
Lately, there's been some formalization of the definitions of mocks, stubs, fakes and dummies, which Fowler popularized through his site with his article Mocks aren't Stubs by introducing the concepts from Gerard Meszaros' xUnit patterns book. I haven't read the book, but the definitions are sensible.
The article attempts to clarify the Mock and Stub concepts, while trying to separate them from the testing styles known as mockist TDD and state/classic TDD. In my opinion, the article fails because the very concept of a Mock is quite different in the mind of one or the other kind of TDDer.
This is further aggravated by the fact that to the average developer mock and stub (even fakes) are completely indistinguishable and used interchangeably in practice. This may also be in part because most developers (average or otherwise, by chance or by decision) are not using any mock framework at all (which would introduce them to the more strict concept of a mock) and typically live in a world of manual "mocks" that gets them through various stages I outlined in a previous post. For people doing manual mocks, there's always a bit of a stub, a bit of a (true) mock, a bit of a fake on each mock, even at various stages during the life of a particular mock.
I'm realizing that for most pragmatic guys (like pretty much everyone at my own company, but also others), the distinction is very much useless. So-called mockists will insist that mock verification is an intrinsic part of the definition of what a mock is. I don't think so, and Wikipedia only states the distinction between mocks and fakes as a preference of "some authors", citing Michael Feathers. I believe this somewhat artificial distinction has been further reinforced by pretty much all mock libraries, therefore restricting the meaning of a mock in practice to those that follow very specific usage conventions imposed by these libraries.
To a pragmatist and classic/state TDDer, a mock is nothing more than a test aid to help a test pass. It's not a core part of the test. It's considered accessory and supplemental at best. The core of the test is the object under test and its externally observable behavior and state, with all its internal details as much as possible protected with strong encapsulation. If some interaction with external dependencies is required to test a particular behavior, then it's perfectly acceptable to mock/stub/fake that, but only to the extent that assertions can be made about the object under test, not necessarily about the mocks themselves.
A lengthy and fruitful discussion I am having with Ayende (of Rhino Mocks fame) made me realize that naming something "mock" that does not adhere strictly to the restrictive concept of mock that mock libraries have imposed is bound to cause disagreement among "pundits" in the TDD camp (especially with mockists). But I also think the generic concept of a "mock" in the general sense is used much more extensively than "stub" or even "fake".
So, MoQ will not be renamed to anything like StubQ or the like, because (besides not being as cool a name) I firmly believe that we should be more flexible about what we call mocks, just because that's the reality of most programmers anyway, and it's the way the concept is used, regardless of what we "the other 20%" try to make them believe.
Anyway, happy mocking without remorse if you don't verify your mocks ;). It's all right as long as it gets your (mostly classic) tests green.
Most mocking frameworks, and especially the two most popular ones, Rhino Mocks and TypeMock, use a record/reply/verify model where the developer invokes members on the mock during the record phase, does a replay to prepare the mock for those expectations, and finally do a verify before the test ends.
From Rhino documentation (emphasis mine):
Record & Replay model - a model that allows for recording actions on a mock object and then replaying and verifying them. All mocking frameworks uses this model. Some (NMock, TypeMock.Net, NMock2) use it implicitly and some (EasyMock.Net, Rhino Mocks) use it explicitly.
Well, it's not true anymore that *all" mocking frameworks use record/replay :).
Anyway, an example from Rhino is:
[Test]
public void SaveProjectAs_CanBeCanceled()
{
MockRepository mocks = new MockRepository();
IProjectView projectView = (IProjectView)mocks .CreateMock(typeof(IProjectView));
Project prj = new Project("Example Project");
IProjectPresenter presenter = new ProjectPresenter(prj,projectView);
Expect.Call(projectView.Title).Return(prj.Name);
Expect.Call(projectView.Ask(question,answer)).Return(null);
mocks.ReplayAll();
Assert.IsFalse(presenter.SaveProjectAs());
mocks.VerifyAll();
}
I find this record/replay/verify model somewhat unnatural. When you follow the typical progression explained in Mocks, Stubs and Fakes: it's a continuum, you end up thinking about your mocks as invokers of your delegates/lambdas. There's no especial concept to understand. It's "plain .NET" if you will. The above test in MoQ (which is the result of taking that very progression and turning it into a generic mock framework) looks like the following:
[Test]
public void SaveProjectAs_CanBeCanceled()
{
string question, answer;
var projectView = new Mock<IProjectView>();
var prj = new Project("Example Project");
var presenter = new ProjectPresenter(prj, projectView.Object);
projectView.Expect(x => x.Title).Returns(prj.Name);
projectView.Expect(x => x.Ask(question, answer)).Returns(null);
Assert.IsFalse(presenter.SaveProjectAs());
}
Note that the only assertion is the one on the presenter.SaveProjectAs. There are absolutely no "side effects" from using the mock framework. It's just a helper for your traditional state/classic test. And MoQ is mostly syntactic sugar for what you could have done yourself.
Verifying the mock slowly but almost inevitably takes you down the path of focusing your tests in the interaction as opposed to the state of the object under test. I agree with mockists that sometimes an interaction test is the only way to ensure a given behavior (cache hits/misses is the most evident one), but it's more of the exception than the rule IMO.
That's why MoQ doesn't provide a Verify method on its Mock<T> class. I strongly believe that an API that makes it very easy for you to do the "right thing" is the way to go. You can still verify the interactions with MoQ, but it's going to be a bit more work, keeping flags of invoked members and setting them from callbacks. This way, the mocking framework takes you away from that kind of testing by making it more difficult.
Highly recommended reading: Fowler's article Mocks aren't Stubs. It's a very clear characterization of the types of so-called Test Doubles (mocks, fakes, stubs, etc.) you can use to aid your unit testing needs, but also of the kinds of TDD you can do: classic (or state) TDD and mockist (or interaction) TDD.
I got the feeling that the article seemed a bit biased towards mockist TDD, only to see in the "So should I be a classicist or a mockist?" section that Fowler himself is a classic TDDer :o). Maybe it's because mockist TDD is a newer approach to TDD and therefore required a more extensive explanation. Or maybe it's just that the article title is a bit misleading as its content is about mocks in the strict sense used by mockists, and not in the general sense I think of them (as generic aids in unit testing).
I'm a state testing guy myself, but I always found it very annoying having to create all those little "mocks" to help me test classes that had dependencies. So I always thought a mocking library would be very handy to use. And as Fowler says, "it's often hard to judge a technique without trying it seriously". So I set to use a mocking framework (NMock2) throughout a project, to learn what it feels like.
At first it felt very good not to have to create mocks manually, but very soon I started to feel the smell in all those lengthy setups where we were basically duplicating in mock expectations the entire interaction between collaborating classes which were completely unrelated to the object under test. I remember even having to set expectations for a component attaching to events raised by a dependency, which was completely unrelated to the core test and a mere internal detail about the communication between these components.
We suffered dozens of tests fail not only as a consequence of refactoring, but also as part of regularly added new features (i.e. a new event being raised by a collaborator). It was painful to get into any but the most trivial refactoring. And it went this way for months, not just for a week of trial. We still have the mockists tests we did back then, but over time we went back to manually creating our mocks, mostly following the approach I explained in Mocks, Stubs and Fakes: it's a continuum.
It's important to realize that it's not a failure of the particular mocking library we used. It's a by-design "feature" of mockist TDD, and one that is hard to avoid as most libraries are designed around the same principles. The sole presence of a "Verify" method on the mock is a smell to me, one that will slowly get you into testing the interactions as opposed to testing the observable state changes caused by a particular behavior.
So, if you wonder why Moq doesn't provide a Verify method, now you know why :). It's IMO the most classic/state TDD-friendly mocking library available, and the most minimalist too :).
Highly recommended reading: Fowler's article Mocks aren't Stubs.
Generically called (by Gerard Meszaros's xUnit patterns book) Test Doubles, all three kinds of test aids are intended to replace real implementations of dependencies of the object under test. From Fowler's article, we learn the difference between them as explained by Meszaros:
-
Dummy objects are passed around but never actually used. Usually they are just used to fill parameter lists.
-
Fake objects actually have working implementations, but usually take some shortcut which makes them not suitable for production (an in memory database is a good example).
-
Stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what's programmed in for the test. Stubs may also record information about calls, such as an email gateway stub that remembers the messages it 'sent', or maybe only how many messages it 'sent'.
-
Mocks are what we are talking about here: objects pre-programmed with expectations which form a specification of the calls they are expected to receive.
I will refer to this precise definition of these concepts by using the Capitalized name (i.e. Mock) as opposed to the more informal and common definition of them, such as mock (lowercase).
I feel that this separation is not very realistic in practice. Any given test double can be considered (and may become at any point in time) more of one or the other, except perhaps for the more strict case of mocks automatically created from some mocking libraries. Let's see why.
Consider Fowler's case of an Order that must be Filled from an IWarehouse:
interface
IWarehouse
{
bool HasInventory(string productName, int quantity);
void Remove(string productName, int quantity);
}
class Order
{
public string ProductName { get; private set; }
public int Quantity { get; private set; }
public bool IsFilled { get; private set; }
public Order(string productName, int quantity)
{
this.ProductName = productName;
this.Quantity = quantity;
}
public void Fill(IWarehouse warehouse)
{
if (warehouse.HasInventory(ProductName, Quantity))
{
warehouse.Remove(ProductName, Quantity);
IsFilled = true;
}
}
}
Straight-forward enough. In order to unit test the Fill method on the order, you might start by creating a Stub (I'm still calling the class "Mock*" as it's the generic term I usually use to mean "Test Double", which is less common):
class
MockWarehouse : IWarehouse
{
public bool HasInventory(string productName, int quantity)
{
return true;
}
public void Remove(string productName, int quantity)
{
}
}
This is the "by the book" definition of a Stub. From this, your first unit test can pass:
[Test]
public void FillingFillsOrder()
{
var order = new Order(TALISKER, 50);
var mock = new MockWarehouse();
order.Fill(mock);
Assert.IsTrue(order.IsFilled);
}
But that's kind of incomplete, as you don't know if the order actually called the warehouse to remove the item (even if you'll get a 100% code coverage in this case, which leads to the "obviousness" that coverage != thorough testing). So you typically save the values on the Remove call in the stub like so:
class
MockWarehouse : IWarehouse
{
public string RemovedProductName;
public int RemovedQuantity;
public bool HasInventory(string productName, int quantity)
{
return true;
}
public void Remove(string productName, int quantity)
{
this.RemovedProductName = productName;
this.RemovedQuantity = quantity;
}
}
And add the corresponding assertions to the test:
[Test]
public void FillingFillsOrder()
{
var order = new Order(TALISKER, 50);
var mock = new MockWarehouse();
order.Fill(mock);
Assert.IsTrue(order.IsFilled);
Assert.AreEqual(TALISKER, mock.RemovedProductName);
Assert.AreEqual(50, mock.RemovedQuantity);
}
And we're still in the realm of a proper Stub. Next thing is, another test might need to modify the response from HasInventory depending on the arguments, so you can test what happens when there's not enough inventory for a particular item. At this point, you can pass the mock a boolean in a constructor with the canned response it has to return:
public MockWarehouse(bool hasInventory) { }
In more realistic cases, however, the returned value may even be a factor of the received arguments in the call. So you can either go for a full Fake implementation, or you can simply pass a delegate that the method will callback to determine the return value:
class
MockWarehouse : IWarehouse
{
public delegate bool HasInventoryHandler(string productName, int quantity);
private HasInventoryHandler hasInventory;
public MockWarehouse(HasInventoryHandler hasInventory)
{
this.hasInventory = hasInventory;
}
public bool HasInventory(string productName, int quantity)
{
return hasInventory(productName, quantity);
}
public void Remove(string productName, int quantity)
{
this.RemovedProductName = productName;
this.RemovedQuantity = quantity;
}
}
In this very simplistic case, it's obviously overkill, but in most real cases, externalizing the mock implementation this way can lead to highly reusable mocks. Taken to the extreme (and to a more usable API), you can create your mocks so that it implements the interface explicitly and has all its members as getters/setters of corresponding delegates for the methods you want to implement externally:
class
MockWarehouse : IWarehouse
{
public Func<string, int, bool> HasInventory { get; set; }
public Action<string, int> Remove { get; set; }
bool IWarehouse.HasInventory(string productName, int quantity)
{
if (HasInventory != null)
return HasInventory(productName, quantity);
return false;
}
void IWarehouse.Remove(string productName, int quantity)
{
if (Remove != null)
Remove(productName, quantity);
}
}
Such a mock would be used from your test as follows:
[Test]
public void FillingFillsOrder()
{
var order = new Order(TALISKER, 50);
var mock = new MockWarehouse();
var removed = false;
mock.HasInventory = (productName, quantity) =>
productName == TALISKER && quantity == 50 ? true : false;
mock.Remove = delegate(string productName, int quantity)
{
Assert.AreEqual(TALISKER, productName);
Assert.AreEqual(50, quantity);
removed = true;
};
order.Fill(mock);
Assert.IsTrue(order.IsFilled);
Assert.IsTrue(removed);
}
I'm using C# 3.0 lambda notation for the first delegate just for brevity. The second delegate is passed as a regular C# 2.0 anonymous delegate. The HasInventory delegate will only return true if it receives the specific values in the expression. This is a very powerful and flexible approach I'm very fond of. It's easy to imagine a code-generator spitting such mock implementations automatically: just give it the interface, and all it has to do is implement explicitly the interface, provide public read/write properties with the same names as the interface names, and optionally create delegates for those method signatures that don't match .NET "predefined" ones (i.e. Action and Func).
Now, this mock doesn't look like a proper Stub anymore, does it? Does it look like a true Mock now? It looks more of a mix, where it can be considered one or the other depending on the usage. For example, if I set the handler for HasInventory as follows:
mock.HasInventory = (productName, quantity) => true;
it would fit the definition of a Stub, as it's returning a canned value regardless of the invocation arguments. I can also set it like a Stub for the Remove method:
string removedProduct;
int removedQuantity;
mock.HasInventory = (productName, quantity) => true;
mock.Remove = delegate(string productName, int quantity)
{
removedProduct = productName;
removedQuantity = quantity;
};
order.Fill(mock);
Assert.IsTrue(order.IsFilled);
Assert.AreEqual(TALISKER, removedProduct);
Assert.AreEqual(50, removedQuantity);
You might consider this a case of "recording the calls" and their arguments. On the other hand, using it as first written makes it look more like a Mock.
Sometimes the overhead of setting multiple "expectations" handlers like this in a complicated interaction is so annoying that you end up having a more realistic implementation (i.e. a MemoryWarehouse, a Fake) to cut down test setup code.
As you can see, knowing the categorization helps at the conceptual level, but in practice it doesn't add much value, as you navigate the range of options depending on the specific testing needs. And that's a good thing, as they will always adapt to what you need, not the other way around.
That is, if you're manually creating your Test Doubles. I'll talk more about the influence the use of a mocking library can have in the way you test in another post.
(go straight to the snippets if you can't wait ;))
Regardless of whether you use a mocking framework/library or not, as long as you're doing unit testing, you're almost for sure using mocks. Most of the time they are manual mocks typically not even shared outside the scope of a single test fixture as they contain hardcoded values for return types, helper members, etc.
This works well, but it's counter-productive and plain boring. Mocking interfaces just to implement the one or two members you're interested sucks.
Using a mocking framework helps, but they typically introduce undesired side effects:
- Almost every framework I know of requires you to set an expectation for each and every member called on the mocked interface while the tests are running. This includes expectations for attaching/detaching to events, invoking void methods, etc. This causes your unit tests to replicate the entire internal implementation of a given behavior as expectations, and needless to say, this causes any (perfectly valid from the encapsulation point of view) subsequent refactoring of the implementation to break lots of tests that were setup to expect the old interactions.
The setup is typically more involved than the actual unit test itself, and discovering the full chain of calls that should be expected is a painful trial & error exercise until you get the damn interaction right. Needless to say, this can be pretty bad for highly modularized libraries that fragment funcionality in many rather small interacting components.
Psicologically, it also deviates the main focus of the unit test at hand, and over time can lead to an excesive focus on testing the interactions rather than the observable state and behavior from the point of view of the object under test.
- Most frameworks rely on member names passed as strings (i.e. mock.Expect("Foo")), which induces the developer to avoid refactorings that typically cause ripple effects throughout test fixtures. This is especially bad in the light of the previous issue and highly componentized libraries.
What I always wanted was a mocking framework that did just what I already do manually with my mocks (typically setting up fixed return values on methods or properties, calling a callback on the test to check for a call, or maybe throwing an exception), and which doesn't get in the way of refactoring.
In typically manual mocks you don't care about the ordering of calls, about invocations to methods you generally don't care for a given test, about events subscribed/raised by the mock, etc. (we may add these features in the future if there's enough demand, but I don't think they lead to good testing patterns).
Enough intro! Let's see the code!!! Here's what myself and waj got working in about a couple hours of pair programming (further refined and polished over nights and a weekend):
var mock = new Mock<IFoo>();
mock.Expect(x => x.Execute("ping")).Returns("I'm alive!");
mock.Expect(x => x.Execute("update foo")).Callback(() => updated = true).Returns("Got your update!");
mock.Expect(x => x.Execute(It.IsAny<string>())).Throws(new ArgumentException());
Here we expect either a ping or an update. Anything else (It.IsAny) will throw.
Note that everything is strong-typed, and refactoring the Execute method in any way will automatically cause the tests to either stay in sync or fail to compile (i.e. you change the type of an argument or remove it).
The "x" argument in the expect (you can name the variable whatever you want, however) is of the type of the mocked interface, so you call members on it directly.
The It class provides for a kind of wildcard support. There's an IsAny, IsInRange and IsRegex. The coolest one though is the plain It.Is method that receives a predicate!
mock.Expect(x => x.DoInt(It.Is<int>(i => i % 2 == 0))).Returns(1);
Here the mocked object will return the value 1 only if the integer passed to the DoInt method is an even number.
The cool thing about this approach is that you don't need the mocking library to provide all the filters you need, as you can simply pass a predicate for any condition you can dream of.
Moq is an open source project, released under the new BSD license, and available from its project home at Google Code.
Check out the Moq Quickstart wiki page which contains a lot more samples.
