Roy has a post up today about TypeMock, testability, and DI. The age old (ok, it just seems like we've been arguing over this for decades) question comes up again "is TypeMock too powerful?" First, let's go pro-TypeMock because the attraction of TypeMock is pretty easy to understand. I'm sick of fighting with C#'s static typing just to write unit tests with mock objects. Pulling interfaces out just for unit testing is a bit tedious (ReSharper makes both creating the interfaces and bouncing around the code easy enough that that's not a real problem to me). It is code noise that's there for no other reason than to make the compiler shut up.
The fear that TypeMock will "allow" people to write bad designs is partially bogus. Part of the reason that I think TDD leads to better designs because it's painful to write tests for bad code (and by bad, I mean code with poor cohesion and poor separation of concerns). TypeMock will deaden some "pain nerves" that detect bad design by making it possible and even efficient to unit test tightly coupled code (remember that coupling is important for other reasons besides "testability"). TypeMock usage could easily lead to less reusability and extensibility in the code that may turn out to be harmful in the end. All the same though, I'm not too worried about people using TypeMock because TypeMock won't do all that much to help you test bad code. Let me repeat that again. TypeMock won't do all that much to help you test bad code. Testability is more than just being able to mock interfaces. Heck, coupling is quite a bit more than mere interfaces.
If a caller has too much intimate knowledge about the innards of a dependency (tight coupling), setting up the mocking expectations on TypeMock is going to hurt and inform the experienced TDD'er that something is wrong with his or her design. If a class or method is not cohesive, the test setup will still be too arduous for what you're trying to test (does the class do only one thing that's quick to test, or does the thing you want to test only happen in the middle of a bunch of other things).
So, to wrap up: TypeMock does not end the idea of designing for with testability, and is not going to let you get away with a bad design anyway.
As an aside, Dependency Injection and Inversion of Control containers have far more
usages than simply pushing in mock objects. The existence of TypeMock
doesn't even remotely eliminate the need or desire for DI/IoC tools
(especially since I very rarely use the container in a unit test
anyway). Dynamic Languages might signal the upcoming death of the DI tooling, but
TypeMock doesn't (if StructureMap becomes irrelevant, I just get to move on to new challenges).