Rhino Mocks: Void methods using Expect.Call
One of the things that I dislike about Rhino Mocks is the disconnect between methods that return a value and methods that do not. The first are handled quite naturally using Expect.Call() syntax, but the later have to use the LastCall syntax, which is often a cause of confusion.
There is little to be done there, though, that is a (valid) constraint place there by the compiler, can't do much there, right?
Jim Bolla had a different idea, and had a great suggestion, so now we can write this:
IServer mockServer = mocks.CreateMock<IMock>(); Expect.Call(delegate { mockServer.Start(); }).Throw(new InvalidConigurationException()); // rest of the test
It is also a good way to start preparing Rhino Mocks for C# 3.0.
Many thanks to Jim.
Again, the code is in the repository, and will be released soon.
Comments
It's scary how my colleague and I were just talking about this today.
Thanks for the post. It will be very beneficial.
Excellent! I often dislike having to use the LastCall syntax as well. This makes all of my expectations look the same. I like it!
Perfect, I was just thinking the same thing last night too, after writing that 1 millionth mocked void method call expectation this project...
I was just dealing with this again today, this is great.
If you're talking about C# 3.0:
Expect.Call(() => mockServer.Start()).Throw(new InvalidConigurationException());
Sweet!
Man I can't wait to get in to c# 3. Of course until resharper supports it it's pretty much a no go.
w00t!
I guess we VB programmers are out of luck again..
Ulu,
That is unfortunately the compiler fault.
You would get this feature in VB9, though.
Shouldn't the example code actually say...
IServer mockServer = mocks.CreateMock();
Expect.Call(delegate { mockServer.Start(); }).Throw(new InvalidConigurationException());
// rest of the test
Because the current example creates a mock of IMock without showing any relation between it and IServer.