Comments on: Design for Testability Talk

By: VaNTa

VaNTa — Thu, 15 Oct 2009 12:59:19 +0000

Thanks Misko, it’s really great talk.

By: Subb

Subb — Wed, 14 Oct 2009 14:41:18 +0000

@misko, this is what I thought, but my network connection object “A” is asynchronous (AS3). My object “B” needs a connected object “A” so my factory will need to be asynchronous (?) and handle connection errors. Is it really the place for that stuff?

By: misko

misko — Wed, 14 Oct 2009 01:18:18 +0000

@Subb, it is up to the factory, to make sure that the object is injected in the right state.

By: Subb

Subb — Tue, 13 Oct 2009 14:29:07 +0000

Good talk, as usual. Sums up really well most of your post. I have a question tho.

What happen when object A needs another object B in a certain state? Most of the time, this as to do with network connection, i.e when Object B needs to be connected to some end-point to be used by object A.

How do you deal with this kind of dependency?

By: RM

RM — Tue, 13 Oct 2009 07:47:05 +0000

Is there an audio recording that I could play/download. Video download is are a bit much for my connection.

By: igorbrejc.net » Fresh Catch For October 12th

igorbrejc.net » Fresh Catch For October 12th — Mon, 12 Oct 2009 05:07:59 +0000

[...] Design for Testability Talk [...]

By: najcik

najcik — Fri, 09 Oct 2009 07:52:29 +0000

@Zilvinas, @Mark
I do agree with both of you. Really sign under your comments with both my hands But there will always be code you have to cope with and which is not up to the standards, you have to start with something – even Mr. Feathers suggests that you’ll have to do some initial refactoring of the legacy code without tests because it might not be feasible to do otherwise. I certainly don’t advocate to not use DI here just thought a feature like of a mocking framework could be warm welcomed by testers.

@Giorgio Sironi – Well, you can mock subseqent calls and tell the fake to behave differently on each call, can’t you ? If new was mockable how could it be any different ? So I would like alter the behavior of the loader and pass loader mock such that if a new operator is called it loads a different class. If another new is called to create an object of the same class it can be another fake with the behavior needed for the second call.

By: Marty

Marty — Fri, 09 Oct 2009 07:39:04 +0000

I’m still struggeling with how to use the DI aspect in production.

The example with the Login Page you gave and the @Cookie annotation.

From testing creating the LoginPage is obvious, but how does this looks like in production code, where I need different LoginPages with different cookies.

And how does this go straight with your post about injectables und newables ? didnt you advice NOT to mix them ? The loginpage does mix it (String & Authenticator).

So for me this is the dilemma… I dont understand how to solve this problem with DI.

Thanks

By: Giorgio Sironi

Giorgio Sironi — Thu, 08 Oct 2009 17:53:14 +0000

Good talk, I originally have trouble with DI before realizing factories could be injected for the creation of objects with shorter lifetimes.
@najcik: to substituting new operators or static calls by interception seems global state. What if you have two new calls of the same class and want to inject two mocks with different behavior?

By: Zilvinas

Zilvinas — Thu, 08 Oct 2009 17:22:58 +0000

@najcik: There are a few smart(?) people saying that DI is not the only solution to testability. But on the other hand printers don’t build themselves. Let factories build printers. It makes your code more readable, understandable. You have separated responsibilities for building objects and doing something in objects. It’s the same as separating UI from domain. You can do it otherway but most of the time it turns out to be a disaster.