Mocking a huge interface

[A]

I want to mock a third party interface that contains approx. 170
public properties and methods. Executing the test (without debugging)
takes up to 5 seconds, but when debugging the mock instantiation step
takes couple of minutes.

Is there any workaround to somehow reduce the time of execution?

[Ayende Rahien]

This is a known issue with VS 2008, I don't know if it is still there in VS 2010

--
You received this message because you are subscribed to the Google Groups "Rhino.Mocks" group.
To post to this group, send email to rhino...@googlegroups.com.
To unsubscribe from this group, send email to rhinomocks+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rhinomocks?hl=en.

[Tim Barcz]

170? Someone needs to learn SRP and ISP... Good lord.

I would also say don't mock interfaces you don't own...wrap it and provide an interface you do own (will be a very thin layer.

[Stephen Bohlen]

Maybe its single responsibility is to hold every operation known to mankind :)

Seriously, though, if we're certain that this is VS2008-debugger-related I'd be glad to test under VS2010 and report results.  Are we saying that all we need to repro this issue is ANY interface with 170 props/methods --?

Steve Bohlen
sbo...@gmail.com
http://blog.unhandled-exceptions.com
http://twitter.com/sbohlen

[Jonathon Rossi]

There is a comment in this issue that indicates rebuilding DP using the 4.0 compiler will fix the problem:

http://issues.castleproject.org/issue/DYNPROXY-72

Jono

[Stephen Bohlen]

Interesting...but the way I'm reading that is that on the castle site is that its not enough to compile DP using the C# 4 compiler but that it appears necessary to compile it targeting the .NET 4 runtime as well ... is that your impression as well --?

It seems to me that if recompiling using the .NET 4 C# compiler but still targeting .NET 3.5 will resolve it then we could (potentially) be on to something here but that if we need to recompile DP actually targeting the .NET 4 CLR then this 'fix' would be a pretty significant breaking change for RM (at least in as much as a bug-fix shouldn't result in a runtime change being req'd).

Steve Bohlen
sbo...@gmail.com
http://blog.unhandled-exceptions.com
http://twitter.com/sbohlen

[Jonathon Rossi]

I'm going purely on the comments written there for this, because the other debugger problem we had was when you were generating several hundred proxy types:
http://issues.castleproject.org/issue/DYNPROXY-98

That issue is also described in this threads:
http://groups.google.com/group/castle-project-users/browse_thread/thread/4d1d294513d483fa/2d65e6f25f9121e6
http://groups.google.com/group/castle-project-users/browse_thread/thread/39952b3c51a131c/ee4a5a607e499d48

It is probably worth profiling the application with the debugger attached to see where the test is spending those minutes.