So why not do the proper thing and make sure you can control your downward dependency, such that you do not need to revert to a solution like Moles?

We had the issue here, we were using Moles for the 'legacy' project and some members of the team suggested to continue using it for the new project. I explained that Moles is great if you can not convince the stakeholders to allow you to make your project more testable (e.g. by using Dependency Inversion). So now we are going TDD (Test Driven Design) and are getting great feedback from NCrunch while writing true unit tests.

Eventually, for NCrunch, it would be great to add Moles support, if at all possible. The way I understand both products instrument/profile the code under test to gain control of what code is being run. I doubt it would be possible to run the MolesHost and still be able to capture the information needed. (Note: I'd love to know more about how these systems work, it is by instrumenting code or is it by using the profiling api, but I don't seem to be able to create the time for such explorations. I'm just really happy there are people building these tools and that they work, though!)

I think that the general idea behind using DI for a situation like this would be to try to author the tests in a way that would allow you to comfortably test private methods through the public interface. DI proponents would argue that if the private method is complex enough to warrant being isolated for testing, then probably it should be extracted and tested as a separate component/class. I'm personally not big on the idea of testing private methods directly (due to coupling concerns), though naturally I can't hold any bias on this in terms of what NCrunch should or shouldn't allow :)

Anyway, Moles has many other advantages outside of the private/public method testing argument in the fact that it allows you to stub out parts of an application that are not easily abstracted away from a component under test (i.e. HttpContext in ASP.NET).

I haven't yet had time to have a good look at the mechanics of how Moles works. My suspicion is that it would use the profiling API in the same way that TypeMock Isolator does, in which case support for it shouldn't be a big deal (as NCrunch is already integrated with TypeMock Isolator). I'll make a note to have a look at this in a future revision.

Thanks for posting :)

rlarno, you nailed it. The dependencies I'm trying to sever are between public methods and the private methods they call. We will probably end up solving the problem in two ways:

1) If the private method is being called by more than one consumer (within the class that contains it), refactor it to a helper class, mark it internal, and test it
2) If the private method is being called by one and only one consumer (again, within the class that contains it), test it directly and mole it when testing the consumer.

It's that second case that makes NCrunch angry.

Thanks for the info, Remco. I'll look forward to seeing that in some future version.