+972 52-548-6969
Rhino MocksExtending the Mockable
time to read 1 min | 148 words
Well, thanks to Ivan Krivyakov, who did most of the work, this is now possible:
[Test] public void CanMockAppDomain() { MockRepository mocks = new MockRepository(); AppDomain appDomain = mocks.RemotingMock<AppDomain>(); Expect.Call(appDomain.BaseDirectory).Return("/home/user/ayende"); mocks.ReplayAll(); Assert.AreEqual(appDomain.BaseDirectory, "/home/user/ayende" ); mocks.VerifyAll(); }
As you can guess, this means that Rhino Mocks now also integrate with the Remoting infrastructure of the CLR. There are are quite a few types that inherit from MarshalByRefObject, and all of those are now mockable by Rhino Mocks.
I tried to compile a list of stuff that people wanted to mock but where unable to before, but the only thing that comes to mind is: System.Drawing.Graphics
The main benefit is if you want to mock WinForms stuff, since all of those inherit from MarshalByRefObject. Another interesting new mockable is System.IO.FileSystemWatcher.
The change is on the repository, but I am not making a release yet, I want to do some more testing first.
More posts in "Rhino Mocks" series:
- (30 Jun 2008) Getting closer to conclusion
- (29 Jun 2008) The role of Stub vs. Mock
- (29 Jun 2008) To be strict or not?
Comments
Ayende, you really rock :D. I must admit that I really love Rhino Mocks.
Alk.
Nifty both dynamic mocks and transparent proxies behind the same interface! We could do ContextBoundObject too, I guess. There aren't all that many of those though.
Wait, isn't the Graphics class sealed?
Ulu,
Yes, it is.
It is still mockable now, cool, eh?
It's so cool it looks like black magic. I mean, I can imagine how you could theoretically mock virtual methods, but this..
Anyway, this is sort of moving the same direction as TypeMock.. which is considered bad for some folks..
Not for me though, I still insist that too many possibilities can't be bad, at least for an experienced developer. So, big big thanks Ayende and Ivan for this!
Comment preview