unit testing legacy code: limits of "extract and override" vs JustMock/TypeMock/moles?

Given the following conditions:

• a very old, big, C# legacy code base with no testcoverage whatsoever
• (almost) every class derives from some interface
• nothing is sealed

What are the practical benefits of using profiler-API-driven solutions like JustMock and TypeMock, compared to using extract&override + e.g. RhinoMocks? Are there cases I'm not aware of, besides circumventing private/protected, where using TypeMock/JustMock etc. is really needed? I'd especially welcome some experience from people having switched to one of the products.

Using extract&override seems to solve all problems when handling old legacy code, the refactoring seems dead simple, and the possibility for introducing bugs seems very minor. Is the benefit writing less test code? More beautifull classes with less开发者_StackOverflow virtual protected stuff? Right now, I don't 'get it', although I understand it's very helpfull to first test private methods in isolation, as public methods may be too large under the hood in such old legacy codebases.

If you don't know what extract&override is: see here.

There are many differences between the frameworks which do not regard the technology on which the frameworks built on.

For example:

• API - every framework has different notations and defaults (e.g. strict defaults vs. relaxed defaults)
• Support - the propriety frameworks usually offer support with the licenses
• Price - this is not a matter of usage but requires budget

The main advantage of Extract&Override is that it requires some refactoring, if the code you're working on is neglected, it's gives a good chance to go over it and refactor it toward better code and not just for testability.

The main advantage of using an Isolation framework is that you do not need to change the code under test (if it's a large codebase it could take long time just to refactor it for testability). In addition, the Isolation frameworks do not force you into specific design, this could be helpful if the legacy code matches better its existing design. Another feature which is useful in legacy code is swapping instances created in the code under test, usually refactoring instantiations takes more effort and this can be saved. Last thing is faking 3rd party code - using isolation frameworks you can isolate code which is not yours without using wrapper classes.

Disclaimer - I work at Typemock