Design for testability vs. API as a deliverable (or test-what’s-designed) is something I’ve blogged about before and it does sort of boil down to a religious debate. I’m currently on the “test what’s designed” side because, for me, API is a deliverable. I’m also not a big fan of some of the sacrifices you have to make when you design for testability, like losing your encapsulation.

Regardless of your views, mocking is still something you can most likely take advantage of in your unit tests. You could use one of the open source frameworks out there like Rhino.Mocks. It’ll work. If you have access to TypeMock, though, or if your project already has TypeMock in it, there’s no need to move away from it or be scared that it’s “too powerful.”

You can still design for testability using TypeMock. You just need to follow one simple rule:

Restrict your TypeMock use to “Natural” mocks.

That’s it. That’s the secret. As long as you stick to the TypeMock RecorderManager and RecordExpectations objects when setting your mocks up, only using “Natural” mocks, you can still satisfy your design-for-testability urges.

And, hey, it doesn’t hurt that you’ll be able to do those more powerful things should you need to, right?