I am going to have to published builds of Rhino Mocks, the first is the
usual one, the second is the unmerged one.
On Wed, Oct 1, 2008 at 9:37 PM, Alex Scordellis
<[EMAIL PROTECTED]>wrote:
>
> I recently posted [1] about a problem I was having using Rhino Mocks'
> logging interface in version 3.4, which was caused by some of the
> Castle.Core interfaces being internal in Rhino.Mocks.dll. I've also
> had problems in RM v3.5 trying to decorate mock objects with
> additional interceptors. For me, I would like IInterceptor and
> IInvocation to be public. Others have had problems that can be solved
> by making them internal [2,3].
>
> I think that the types should be exposed. This causes two problems
> 1) Exposing stuff that people don't use - a subjective point
> 2) Creating ambiguous type matches at compile time. There is
> workaround to this - using assembly namespace qualifiers [4].
>
> However if these types are not exposed, it's impossible for me to do
> what I want to do. I'm trying [5] to write a tool [6] which integrates
> closely with Rhino.Mocks to improve the quality of mock-based tests
> [7]. In my opinion, it's better to require a workaround for one use
> case to enable another, than completely block the second use case.
>
> I guess this needs a decision on what direction is preferred for
> Rhino.Mocks, but without a change, I won't be able to enhance the
> ecosystem that exists around Rhino.Mocks.
>
> Alex
>
>
>
>
> Specific details of what I can't do:
>
> In v3.4, I can't implement IExpectationLogger - Ayende confirms that
> this is a known limitation[1].
>
> In both versions, I can't create additional implementations of
> IInterceptor, because IInterceptor is internal. I can reference
> Castle.Core.dll and implement IInterceptor from there, but then I
> can't assign that to the __interceptors field because that's an array
> of IInterceptors from Rhino.Mocks.dll and they are considered to be
> different types. The following code compiles, but throws an execution
> at runtime.
>
> private static void Wrap(object mock)
> {
> var __interceptorsField = mock.GetType().GetField("__interceptors");
> var __interceptors =
> ((global::Castle.Core.Interceptor.IInterceptor[])
> __interceptorsField.GetValue(mock));
> __interceptorsField.SetValue(mock, new
> global::Castle.Core.Interceptor.IInterceptor[] {new
> DecoratingLogger(__interceptors[0])});
> }
>
> public class DecoratingLogger :
> global::Castle.Core.Interceptor.IInterceptor
> {
> // Implementation
> }
>
>
> [1]
> http://groups.google.com/group/RhinoMocks/browse_thread/thread/1b27cc3330a9d5bb
> [2]
> http://groups.google.com/group/rhino-tools-dev/browse_thread/thread/f3f55052e26eece4
> [3]
> http://groups.google.com/group/rhino-tools-dev/browse_thread/thread/5364d1e9eb018422
> [4] http://www.jetbrains.net/jira/browse/RSRP-73777
> [5]
> http://groups.google.com/group/synthesized-testing/browse_thread/thread/58a51dd57d32db8d
> [6] http://no-new-ideas.blogspot.com/2008/09/dogfooding-nsynthesis.html
> [7] http://nutrun.com/weblog/synthesized-testing-a-primer/
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Rhino Tools Dev" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/rhino-tools-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
