Mocking frameworks and isolation frameworks are really two similar but different things. Mocking and stubbing frameworks typically are referenced libraries that allow you to create a stub implementation of an interface (to fake out behavior) or mocking (to verify that behavior was called). Isolation frameworks generally work at the CLR and allow you to instrument into just about any area of code (your own others) you want.
Moles (which is part of Pex) is an isolation framework still in the research division of Microsoft (http://research.microsoft.com/en-us/projects/pex/). With Moles, you can pretty much isolate any section of your code (or any code in the CLR) and control how it behaves. For example with Moles, you could intercept the DateTime.Now() and return a set date and time to use for testing date-dependent calculation. It is also useful when you have a black-box third-party library that you cannot control.
The downside to Moles is that it is a little bit more complicated than using a mocking framework like Moq or RhinoMocks. This added functionality makes Moles learning curve a little steeper. Also, while you can stub an interface with Moles fairly easily and use it in a CI build, when you actually instrument into Moles you "mole" and generate a new assembly with the proper hooks into new .dll. On larger projects, this might increase the build-time slightly. Finally, I ve had some issues getting Moles to work in TFS build and test deployments (but that could just be me).
I wouldn t really make this an "either-or" situation. I would primarily use Moq for most of my needs and try to write my code to be testable using a conventional framework. If, however, you get stuck in a situation where you cannot easily isolate your code for various unit tests, I d use Moles for those situations.
Finally, go read Martin Fowler s article "Mocks Aren t Stubs" (http://martinfowler.com/articles/mocksArentStubs.html). In my opinion it is the best description of what you really want to try to do with mocking and stubbing.
