search

phuccaoca123 / mb-unit

Automatically exported from code.google.com/p/mb-unit
0 stars 0 forks source link

(crazy idea) Build an MbUnit plugin that supports runtime dynamic interception of any method call #25

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
When testing legacy code, it is sometimes impractical to refactor it to
make it easier to work with.  Sometimes code is so test hostile that one
must resort to mocking out non-virtual or non-public parts of the framework
to be able to make any headway at all.  Tools like TypeMock exist to solve
this problem.

In particular, Rhino.Mocks can't handle mocking non-virtual or non-public
methods because it uses DynamicProxy to generate dynamic subclasses. 
Moreover it can only provide assistance with situations in which the point
of instantiation of the mocked dependency is under the control of the test.

However, because MbUnit load test assemblies itself into an isolated
environment, it is in a good position to provide extra assistance for
runtime dyamic interception of any method call.  An MbUnit plugin could
conceivable extend the MbUnit loader to enable this behavior on demand. 
The same plugin could then expose its interception services as an
alternative to DynamicProxy that Rhino.Mocks or other tools could use.

Here are four possible approaches:

1. Use Mono.Cecil to deconstruct and load assemblies into the dynamic
assembly context of the isolated AppDomain with Reflection.Emit.  Then use
MethodRental to instrument the code on demand as needed.

2. Use Mono.Cecil to deconstruct and fully instrument the assemblies that
require interception.  Then add hooks into the instrumentation on demand.

3. Load the test assemblies into a separate CLR process and install a CLR
profiler hook to force recompilation and instrument the code prior to JIT
compilation on demand.  This option has the downside of being very complex
to implement, disable debugging, and preventing the use of other code
profiling tools like NCover.

4. Wait for Microsoft to provide a real AOP solution...

Original issue reported on code.google.com by jeff.br...@gmail.com on 28 Aug 2007 at 8:16

GoogleCodeExporter commented 8 years ago 
I implemented a proof-of-concept implementation add-on for Gallio some time ago 
based on option #1 and #2.

Original comment by jeff.br...@gmail.com on 30 Oct 2007 at 2:16

GoogleCodeExporter commented 8 years ago

Original comment by jeff.br...@gmail.com on 19 Nov 2008 at 7:59

GoogleCodeExporter commented 8 years ago

Original comment by jeff.br...@gmail.com on 19 Nov 2008 at 8:01

GoogleCodeExporter commented 8 years ago 
Meh.  There isn't much demand for this sort of thing considering the effort 
required
to make it useful.

Original comment by jeff.br...@gmail.com on 23 May 2009 at 1:47