Roy recently posted his thoughts on Typemock - whether it's too powerful and will kill TDD. His conclusion seems to be a confident no, and he argues well, but I have to disagree with some of his points.

However, first of all, I have to state that I find Typemock an amazing product that definitely has a raison d'être. If I ever find myself in the situation where I need to deal with an (otherwise) untestable legacy application, I would definitely use Typemock to develop a suite of unit tests that could work as a safety net while I refactor the application towards testability. In that scenario, Typemock can help, and as far as I'm aware, it's the only product on the market that can do what it does.

Incidentally, that covers Roy's argument number 3, and since I agree, I'm not going to spend much more energy on that. His other arguments, hower, I think warrant some scrutiny.

"You can still design for testability and use Typemock"

Yes, I agree, but I can also still design for testability and use Rhino Mocks, so why should I use Typemock? TDD and how to achieve proper isolation between dependencies are techniques deeply ingrained into the way I write code, but still, why would I want to waste my brain power constraining myself instead of having a tool do that?

My family and I recently spend an entire month on vacation in Florida, and since it was warm and you can buy excellent ice cream, I came back larger and heavier than when I left. I want to get rid of that extra weight again, and to do so, I try to eat more healthy, and particularly no ice cream, chocolate, etc. Now, it would be more 'powerful' for me to keep those items in the house, but that would mean that I would have to exert much more self-discipline to not eat it when the need arises. Instead, I voluntarely choose to constrain my situation by making sure such items are not to be found in the house.

This situation is entirely analogous to the choice between Typemock and other, more traditional, mocking frameworks. I don't want to pick a tool that's too powerful for the job, and then spend energy disciplining myself, when I can pick another tool that does this automatically for me.

"If you were doing bad design before, the tool won't help you, just the technique."

Okay, but if that's true, Typemock will not help me, either.

In any case, I don't believe that this statement is true. The very benificial constraint introduced and enforced by a classic mocking framework can force you to think about things you wouldn't otherwise have considered.

Back when I started with TDD I was a fairly experienced (5 years) developer, but I still had a lot to learn (I still do). I'd heard about unit testing, the test-first principle and something called NMock, and that was about how much I knew about TDD and designing for testability. During development of a fairly complex piece of software with a lot of weird business logic, I repeatedly had a very enlightening experience: I designed a bit of the API to address a business problem only to discover that I couldn't test it. That invariably caused me stop and rethink my design, and I always came up with an alternative that allowed me to test my code. As I've later learned, I simply discovered a lot of the patterns in xUnit Test Patterns by myself.

The point is that the tool helped me become a better software designer. This may be the case for some developers, while others will probably just give up on the way - I'm not saying that it's a one-size-fits-all solution, but that there are situations where the tool actually helps you become a better developer (FxCop/Code Analysis is another good example). If you approach the tool with an open mind, it can help you!

"Sometimes you just can't refactor your legacy code into testability."

As I wrote above, I totally agree, and Typemock is an excellent choice in that case, but that doesn't mean that Typemock is the best choice in other scenarios. Dealing with legacy code is a situation distinctly different from greefield development, and I don't believe that the choices of tool, strategy, technique etc. logically carries over from one category to the other.

"Pair Programming, Test reviews and Design reviews trump any tool"

No argument there, but again, this just put Typemock on par with all the other mocking frameworks out there.

"If you're not sure how you'd design something and test it, you can always ask!"

Yes, and you are also welcome to ask me about design for testability.

However, to pose a question at all requires that you realize that you have a problem in the first place. Since Typemock can mock anything, you may be happily chugging along without realizing that there's something fundamentally flawed about your design. If that's the case, why would you ask a question about testability in a forum?

What I like about traditional TDD is that it stops you if you are trying to do something wrong, and that should prompt you to ask!

In short, I'd currently pick Rhino Mocks for all greenfield development. For dealing with legacy code, I'd pick Typemock.