Comments on: Subverting TDD as a design tool

By: ulu

ulu — Sun, 02 Aug 2009 09:14:46 +0000

How do you decide which dependency should be explicit? Which part of the framework is a “dependency”? We all depend on System.String after all..

Knowing your dependencies is important, I agree, but what do you gain in this particular case?

Sometimes you use DateTime.Now in just one method of your class. do you still use a constructor injection? That is, when you go the ISystemClock way.

As for the Func way, isn’t it the same design as with DateTime.Now, only testable?

By: Jeremy Gray

Jeremy Gray — Mon, 25 May 2009 17:15:10 +0000

@Jimmy – I hear ya. I go back and forth on this a bit myself, and suspect that there is a happy medium where certain things are just used so widely (and/or by types you’d rather not use ctor injection on) that statics/funcs may give the best result while using injected interfaces and their implementations for everything else.

By: bogardj

bogardj — Sat, 23 May 2009 21:01:25 +0000

@Jeremy

I’ve gone back and forth myself. It’s pretty straightforward to do double-dispatch with an IClock into an entity…but in some domains where time was _everywhere_, the Func made the most sense. I never worried about putting the replacement back in, however. That was never an issue for me.

By: Jeremy Gray

Jeremy Gray — Sat, 23 May 2009 18:46:54 +0000

@Paco & Jimmy – This is purely anecdotal, of course, but I went down the static/Func combo route once and immediately regretted it. It allows for hidden dependencies to be taken over time and, far worse, was a great source of messy test code (you need to make sure to restore the real func after the test so it has to be gettable, your setup needs to back it up, push the replacement in, run the test, put the original back) that is prone to human error and results in indirect test failures that are dependent on order of test execution and can be difficult to diagnose. Easy to correct once located, yes, but at the cost of the aforementioned messy test code all over the place and for each dependency.

ctor injection FTW!

By: miz

miz — Fri, 22 May 2009 22:43:55 +0000

forgive a dullard’s question: what exactly is being subverted in this specific case?

By: Neil Mosafi

Neil Mosafi — Fri, 22 May 2009 20:28:26 +0000

Couldn’t agree more, be explicit about what you depend on.

Also imagine one day the requirement comes up to run a historical calculation, or to freeze the clock at the start of a message loop so all operations within that loop get the same time, and you will thank yourself for having abstracted that dependency.

By: bogardj

bogardj — Fri, 22 May 2009 20:17:40 +0000

@Scott

Ah yes, design. That makes a lot more sense.

@Paco

Sometimes I want to make the dependency explicit and obvious.

@Justin

The Feathers book is chock full of safe dependency-breaking techniques. We use them quite a lot, even in new codebases.

By: Scott Bellware

Scott Bellware — Fri, 22 May 2009 18:53:57 +0000

Jimmy,

Kind of a point of order: It’s not code that is or isn’t “testable”; it’s design that is or isn’t testable.

Even with TypeMock, the *design* isn’t testable. The reason is that the design can’t be made testable in and of itself without bringing in outside tools (design elements) to make it so. Testability is about whetehr something can be isolated without the need to introduce new factors, such as runtime profiling (TypeMock).

TypeMock doesn’t make anything “testable” unless we opportunistically re-define what what colloquially and commonly mean by “testable”, which is what TypeMock as an entity continues to strive to do. I don’t think they do this nefariously. I honestly don’t think that the TypeMock folks have a reasonable understanding of what is meant by “testable”.

By: Paco

Paco — Fri, 22 May 2009 18:38:29 +0000

Why not everywhere

By: bogardj

bogardj — Fri, 22 May 2009 18:28:18 +0000

@Paco, Jonathan

I go with the Func-y version for entities and such, I personally got it from Ayende.