Cannot create implementations of IExpectationLogger in Rhino Mocks 3.4

4 views
Skip to first unread message

Alex Scordellis

unread,
Sep 30, 2008, 7:04:08 AM9/30/08
to Rhino.Mocks, stoo...@gmail.com
I can't find a way to implement IExpectationLogger in Rhino.Mocks 3.4.
The methods all take a parameter of type
Castle.Core.Interceptor.IInvocation. This is present in
Rhino.Mocks.dll, but it's internal. Adding an additional reference to
Castle.Core.dll doesn't work - the compiler thinks that the version of
Castle.Core.Interceptor.IInvocation from Castle.Core.dll is not valid
for implementing the methods.

Have I missed something or is this a genuine problem?

A bit of background: I am writing a library, NSynthesis, which
captures calls to mock objects during unit tests, then asserts that
all possible implementations of that mock call are unit tested. This
is the theory of Synthesized Testing: http://nutrun.com/weblog/synthesized-testing-a-primer/
I had been using PostSharp to intercept calls from the test to the
mock when setting expectations, but I'd prefer to intercept calls
between the system under test and the mock. I am using the
RhinoMocks.Logger to get notified of these calls, which works fine in
Rhino.Mocks 3.5, but we'd like to support as many versions as
possible.

Maybe there is another way to get Rhino.Mocks to notify me when a mock
object is called. I couldn't find a callback interface but I may be
missing something.

Alex

Ayende Rahien

unread,
Sep 30, 2008, 11:39:28 AM9/30/08
to Rhino...@googlegroups.com
 You need to use Rhino Mocks 3.5 for this.

Alex Scordellis

unread,
Sep 30, 2008, 12:11:08 PM9/30/08
to Rhino...@googlegroups.com
OK, as long as I haven't missed anything!

I'm now looking into alternative ways to capture mock invocations and
I've hit a similar problem. One of the things I'm trying involves
intercepting mock object creation and inserting an extra
Castle.Core.Interceptor.IInterceptor into the __interceptors method.
But IInterceptor is internal in Rhino.Mocks.dll, so we go round again.

I can fix this with a custom build of Rhino.Mocks - with the attached
patch file - but I was wondering what the intention was behind
internalizing most of the Castle stuff. I understand that it's nicer
not to flood users' scopes with types they don't need, but it does
make certain goals (like mine!) impossible! Also, what's the
motivation behind the choice of exposed types available in 3.5RC2?
e.g. why did IInvocation become public between 3.4 and 3.5?

Alex

2008/9/30 Ayende Rahien <aye...@ayende.com>:

.

expose_iinterceptor.patch

Ayende Rahien

unread,
Oct 4, 2008, 3:29:49 PM10/4/08
to Rhino...@googlegroups.com
Applied the patch.
The reasoning is that there are people who are using Rhino Mocks and Castle.DynamicProxy
To those, getting reference errors is a PITA, to say the least.
Reply all
Reply to author
Forward
0 new messages