Typemock and the Pit of Success

Roy Osherove is defending Typemock against accusations that it will "kill design for testability".

Of course it will. It's a technology that allows you to replace any type. Why on earth wouldn't I use it instead of having to factor out all those interfaces and create overridable methods?

Poor design is the path of least resistance with Typemock. And I know that you should be trusting your devs to do things properly, but you've also got a responsibility to set them up for success. Don't hand them a loaded gun.

Typemock is fantastically good at a small number of things - namely testing APIs that you can't factor away (http request and context spring to mind, but I've also been able to refactor around these without too much trouble. Linq to Sql might be another good case, but could you test the logic with Linq to Objects instead?). As soon as you reach for Typemock on your own code, something's gone wrong. And the problem with Typemock is that this isn't enforced.

Put simply, Typemock isn't the Pit of Success.