RE: [Nmock-general] Mocking types with constructors

[Mike B. <mbr...@vi...>]

I didn't mean physically create only one mock class.  I meant logically.  If
the class to mock has 1 base class then obviously you must create 2 mock
classes; one for each real class.  But I'm guessing this is not possible
because NMock does not work by replacing a class, but rather by deriving the
mock class from the real class and overriding all virtual functions.  Is
this correct?  Even if that is true you can still override the virtual
functions in the base class as well as the derived class, so why do you need
the constructor?  Is the constructor necessary because you can't mock the
non-virtual functions and thus they might access non-public data members
which might not be initialized?

The package swapping idea is intriguing.  I had considered something similar
once as a way to mock C functions by swapping .o files.

Mike

> -----Original Message-----
> From: Jim Arnold [mailto:JA...@th...]
> Sent: Tuesday, January 20, 2004 4:21 AM
> To: mbr...@vi...
> Subject: RE: [Nmock-general] Mocking types with constructors
>
>
>
>
>
>
> >Is an object with a mock derived class but real base class really a mock
> >object?  Shouldn't it be all or nothing?  What good is a hybrid?
>
> There's really no other way to do it*.  If a method is expecting
> a concrete
> type, as opposed to an interface type, the object you pass in must be at
> least that type.  It therefore must contain all the fields and members of
> that type "below" its own fields and methods.  You cannot
> substitute it for
> an interface, given the rules of the .Net type system.
>
> >It seems more useful to me to treat the class and its base clases as a
> >single interface and create a mock implementation of that interface
> >replacing the real implementation.
>
> Again, though, the code under test would have no prior knowledge of this
> new interface, and would not accept it.
>
>
> *There are actually a couple of ways to do this, but both are difficult to
> implement and bring their own set of problems.  First, we could use the
> unmanaged profiling API to intercept method calls to real objects, or
> modify the bytecode of a real class at JIT-compile time to call
> out to some
> auditing code.  I actually started doing this last year, but abandoned it
> because a) it requires some pretty hairy C++ and b) it req  uires some COM
> and environment variable magic that would make mocking a more tedious
> excercise than the current, fairly intuitive NMock style.
>
> Second, we could generate a "mock assembly" that looks and smells like a
> real assembly, but has some or all of its classes stubbed out as auditable
> mocks.  We then change references to point to this new assembly, and the
> code under test is none the wiser.  There is a commercial tool by Pretty
> Objects, called POCMock, which does this.  Again, I spiked this last year,
> but ran into some limitations of the Reflection APIs.  Pretty
> Objects use a
> proprietary assembly reader/writer, so it's doable, but non-trivial.
>
> Jim
>