I addressed DI as a concept, not the DI containers out that that do much more (such as interception AOP style and more). Perhaps the working should have been something like "is DI just for testability irrelevant?"

I fully agree that it can still be painful to write tests with typemock if your code under test is highly coupled, which is something I neglected to address.

But it does sound like you feel that TDD (or "naked TDD"?) is more about test driven design than anything else. Perhaps its time to find other ways to drive a better decoupled design than a test framework. It seems though that currently unit testing is as close we get to a self-design-review-in-realtime framework, which I think is not where we should be.

Roy

"All the same though, I'm too worried about people using TypeMock because TypeMock won't do all that much to help you test bad code".

Sorry to be pedantic but I think you missed a "not", which could lead to confusion.

" Testability is more than just being able to mock interfaces.  Heck, coupling is quite a bit more than mere interfaces."

Amen to that.

"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 "

I agree. Some people in our team wanted to do interaction testing against our domain classes so we had two choices:

1) TypeMock - Design as we wanted to.

2) Rhino - Virtual methods and interfaces all over the domain.

The second option certainly wouldn't have improved the design so it was really a bit of a no brainer.

"So, to wrap up:  TypeMock does not end the idea of designing for with testability"

Having read (and in some cases re-read) some of the stuff at mockobjects.com I don't think many people use interaction testing in the way these guys originally intended. In addition much of the original documentation on tests driving design was written before interaction testing kicked off properly (unless my memory lets me down).

"I think the "if testing your code hurts, it's probably bad" is just a nice feedback loop.  I don't have any masochistic idea that "it should hurt!"  TDD is a design activity with a very helpful side effect of unit test coverage."

You are probably right, not enough has been written about this topic yet in my view as it is very interesting.

@Jeremy

Thanks that link was excellent, ta for posting it.

James Carr lists a nice bunch of TDD anti patterns . via Jeremy . Here's one example I run into often

I just wrote an email to someone regarding Typemock . We were discussing why they don't think Typemock

The last two Octobers, I took a moment to reflect on the development tools I was using. It's interesting

The last two Octobers, I took a moment to reflect on the development tools I was using. It's interesting

I think its a mistake to insist on confabulating design-for-testability with 'I have to have interfaces for everything' as this post and others on similar topics tend to do.  Certainly declaring interfaces for everything just to support mocking does add needless 'noise' to a design, but explicit interface declaration is hardly the only way to ensure a class is mock-able even without typemock.

RhinoMocks (and a few other frameworks) support mocking of classes without the need for interfaces so long as the class' methods are declared virtual (or overridable in VB.NET-ese) -- I have used this technique for some time to enable mocking of classes that otherwise don't need an explicit interface defined for them in order to support the rest of the application's design.

Besides, unless you are either hyper-concerned about performance or are 100% sure that nobody will ever need to override one of your methods in a derived class, declaring non-virtual functions is tantamount to declaring the class as sealed: make REALLY sure this is a good idea before you consign some poor maintainer of your app to this23rd ring of hades.

Bottom line, I think, is that tools like typemock have their place alongside a bunch of other tools (that include sound app design principles) but that assuming that design-for-testability == explosion of otherwise unnecessary interfaces is a fallacy.

Pingback from  Eli Lopian’s Blog (TypeMock)  » Blog Archive   » Typemock and Design Issues

Od kilku miesięcy nic tu nie pisałem (oczywiście poza poprzednim nieplanowanym wpisem ). Jak łatwo się

Pingback from  Eli Lopian’s Blog (TypeMock)  » Blog Archive   » Mocking frameworks - dream feature

Pingback from  TDD Anti Patterns | Developer Home

Pingback from  The Case For Typemock | Developer Home

I considerably think that  its a mistake to insist on confabulating design-for-testability with "I have to have interfaces for everything' like this post and others on same topics tend to do."

 [url=http://www.widecircles.com]Social Bookmarking Service[/url]