And how does it work in practice?
Installation was smooth and it didn’t require much configuration. If you want to debug mocked code, you need to link Typemock Isolator with profiler / code coverage tool : the default one is Visual Studio profiler, but more options are supported. Unfortunately my version of Isolator (6.2.3) had some problems with IntelliTrace, so I had to disable it to avoid some irritating message boxes. If you want to use Isolator, you just need to reference its assemblies in your test project and mark your tests with “Isolated” attribute - that’s all.
I’ve managed to use Isolator in many scenarios - starting with situation when I had a full control over my code (so I was able to extract interfaces and introduce factories) and ending with faking .NET Framework class calls - Visual Studio was rock-solid stable, I haven’t seen any major test execution performance drop and what is most important - Isolator played its role very well: I was able to isolate every unit test case separately to make it truly unit testable:
- I am able to make my fake objects return different results each time without making any true implementation
- my fake database is usually a repository pattern-based memory construct (so my test execution time is much, much shorter than before)
- I can easily simulate any exception (even technical one - like lack of physical memory or communication time-out) for test purposes
- I can verify easily if my methods are called when only when I want that (inside the engine “guts”)
- I don’t have to modify original functional code to perform all of that
No, it isn’t.