Menu
▾
▴
FW: [Nmock-general] Mocking types with constructors
|
From: Mike B. <mbr...@vi...> - 2004-01-20 15:00:42
|
-----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 |---------+----------------------------> | | "Mike Bresnahan" | | | <mbr...@vi...| | | m> | | | | | | 19/01/2004 18:07 | | | | |---------+----------------------------> >--------------------------------------------------------------------------- ---------------------------------------------------| | | | To: "'Jim Arnold'" <JA...@th...> | | cc: <nmo...@li...>, <nmo...@li...> | | Subject: RE: [Nmock-general] Mocking types with constructors | >--------------------------------------------------------------------------- ---------------------------------------------------| Was that feature added to Nmock recently? Does it also exist in the Java mock objects framework? I have used both and didn't know such a feature existed in either. 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? 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. Please explain your reasoning. Mike > -----Original Message----- > From: Jim Arnold [mailto:JA...@th...] > Sent: Monday, January 19, 2004 11:44 AM > To: mbr...@vi... > Cc: nmo...@li...; > nmo...@li... > Subject: RE: [Nmock-general] Mocking types with constructors > > > > > > > Yes, currently NMock allows you to mock classes with empty > constructors. You get back a subclass with a real class as > its base. What I'm proposing is to remove the limitation on > empty constructors by either *not* calling any constructor on > the base, or by allowing the user to pass parameters into > GetMockInstance() which would be used to construct the base with. > > Jim > |
