[Nmock-general] Re: MarshalByRefMock, was: NMock

[Tim H. <tim...@gm...>]

Apologies for forgetting to change the subject to something useful.

Also, you mentioned using the ContextBoundObject for AOP, the method
I've used could easily be used for AOP too.

Using the MarshalByRefClass also opens up some rather interesting
possibilities. Because .Net remoting supports Constructor
interception, by using a config file, we could make every instance of
new Foo() actually return a __TransparentProxy that exhibits our
desired mock behaviour. This offers benefits not just for testing, but
also for application code too.

Cheers,

Tim



On 02/11/05, Tim Haughton <tim...@gm...> wrote:
> I've attached the files for reference.
>
> Basically, the MarshalByRefMock class uses a RealProxy. The
> MockInstance property returns the __TransparentProxy from the
> RealProxy, the Remoting magic then calls the funky implementation of
> RealProxy.Invoke, and rather than forwarding the call on to an actual
> instance of the MarshalByRefClass, I simply rip out the method call
> information and call Mock.Invoke (If my memory is working).
>
> It was a bit of an eye opener getting this working for out parameters,
> but that seems to be working now.
>
> The context.....
>
> One of my clients has a heavy remoting architecture, with a lot of
> MarshalByRef classes around. Most of the time we can mock interfaces,
> but sometimes we can't. This method has the advantage that we don't
> need a virtual method in order to mock, plus, there's not actually any
> remoting taking place, in the sense that there are no channels set up,
> no remote objects, and the mocked type is never actually instanciated.
>
> I guess another benefit would be in testing the interaction between
> the WindowsForms classes, as they're all (I think)
> MarshalByRefObjects. Mocking user controls might open up some
> interesting possibilites for TDD'ing user interfaces.
>
> Let me know any questions, flames or suggestions :)
>
> Cheers,
>
> Tim Haughton
>
> On 02/11/05, Owen Rogers <exo...@gm...> wrote:
> > hi tim,
> >
> > On 01/11/05, Tim Haughton <tim...@gm...> wrote:
> > > Apologies for dual email, previous one was mistakenly sent from our s=
pam
> > > catcher account, and isn't usually read.
> >
> > np.  it did get through.  i'm just not on email often enough to
> > respond immediately.
> >
> > > Hi Owen, is NMock accepting any new functionality?
> >
> > sure.  though we're not very active on the list, there's still lot of
> > work that needs to be done.
> >
> > > I've written a new type of dynamic mock that will allow developers to
> > > mock *all* (not just virtual) methods on MarshalByRefObjects. I don't
> > > know if it's been done before, or whether this kind of thing is found
> > > in one of NMock's competitors.
> >
> > cool!  there is a class, RemoteMock i think, which extends
> > MarshalByRef so that i can be proxied.  but i don't know if it allows
> > mocking nonvirtual methods.  so this functionality could be
> > interesting.
> > i've been in a position where we've used
> > MarshalByRef/ContextBoundObjects to support AOP-style logging, etc.
> > but it wasn't really something that we needed to mock to test.  what's
> > the context that's required you to implement this functionality?
> > cheers,
> > owen.
> >
> > ps. we should probably move this discussion over onto the
> > nmock-general mailing list.
> >
> >
> > --
> > Owen Rogers | http://dotnetjunkies.com/weblog/exortech |
> > CruiseControl.NET - http://ccnet.thoughtworks.com
> >
>
>
>