Comments on: How to Think About the “new” Operator with Respect to Unit Testing

By: Objective-C: Frustrations of a Java Programmer | richardrauser.com

Objective-C: Frustrations of a Java Programmer | richardrauser.com — Wed, 07 Jul 2010 18:08:47 +0000

[...] 9. Unit testing: OCUnit and OCMock are fairly immature compared to jUnit and jMock. And furthermore, a number of Cocoa classes include real work in their “constructors.” For instance, NSUrlConnection actually opens an HTTP connection and interacts online in its initWithRequest:delegate: method. The problem this creates is that object creation is tied to real work. This makes dependency injection difficult because we can’t separate the creation of the object from the logic, which would be required in order to substitute a test stub with test logic in its place. Dang. For more on this, see Misko Hevery’s great article on unit testing, object creation and logic. [...]

By: Dependency Injection and Inversion of Control | Geek on the Loose

Dependency Injection and Inversion of Control | Geek on the Loose — Sun, 21 Feb 2010 00:50:45 +0000

[...] Fowler: Inversion of Control Containers and the Dependency Injection pattern [5] Miško Hevery: How to Think About the "new" Operator with Respect to Unit Testing [6] Top 50 Linux Quotes of All Time, #10 [note lkml == Linux Kernel Mailing List] [7] Miško [...]

By: misko

misko — Fri, 18 Sep 2009 15:53:11 +0000

@Radek,

sure, if you are certain that they will always come together, than sure you can do that, but you will never be able to wire it differently. You can get away in few leafs sometimes with this strategy, but it should be rare, the default behavior should always me inject, unless you have a really good reason why it should be something different.

By: Radek

Radek — Fri, 18 Sep 2009 15:41:15 +0000

But, you know, sometimes it just doesn’t make sense to test a house with stubbed kitchen. Let’s say that we have only one, absolutely perfect (”final class”) kitchen. Then there’s no need for DI and builders, kitchen is integral part of the house, and both the house and the kitchen should be treated like a black-box, single entity…

By: Richard Rauser

Richard Rauser — Thu, 17 Sep 2009 15:11:17 +0000

Another great article among many from you, Misko. I’m wondering what you would suggest when building an object graph that includes dependencies on 3rd party libraries that do themselves mix application logic with object creation.

For instance:

private LocalDevice localDevice;

public BluetoothManager() throws BluetoothStateException {

localDevice = LocalDevice.getLocalDevice();

}

Given that LocalDevice is not within my domain and .getLocalDevice() contains logic along with creation of a LocalDevice object, what would you do? Inject it into my BluetoothManager and introduce logic into my object graph builder, or perhaps move localDevice = LocalDevice.getLocalDevice() to an init() method and agree to suffer creating a LocalDevice from within my business logic?

By: fqqdk

fqqdk — Sat, 29 Aug 2009 08:15:07 +0000

Al: that’s true, so if the little nitpicky details of building a House adds up to grow too complex, the creation logic (logic of the HouseBuilder, which is separated from the logic of the House) can also be refactored into multiple objects, so you can have a GeneralHouseBuilder who delegates to a Plumber, so I see no real problems here. And then GeneralHouseBuilder will have a dependency, but we can apply DI to the GeneralHouseBuilder. By the time we get there, we can happily rename it to HouseConstructionShop. It can have a Plumber, an Electrician, and all the other subcontructors injected. But at this level the metaphor is starting to get out of touch, so we should just leave it alone now.

By: Al

Al — Sat, 29 Aug 2009 01:43:37 +0000

True, but it would be inefficient and risky for the general contractor to buy all the construction materials he deems necessary and then inject them into the sub contractor’s shop.

As a practical matter, the sub contractor knows exactly what components are needed, and has much more knowledge of how they fit together. The general contractor has enough to worry about without delving into the implementation details of how the sink and faucet fit together.

If the plumbing regulations change and a different type of pipe is required, only the plumber has to modify his methods. The general contractor does not experience a disruption, does not have to learn new methods, and does not have to change the way he works.

By: misko

misko — Wed, 26 Aug 2009 07:54:56 +0000

@Al,

Unit testing and good OO go hand in hand, not against each other. My code has greatly improved once I have started test first development. Dependency injection helps even more with that. So in your case of wanting different kinds of kitchens you would have a house builder which would be responsible for creating the right kitchen and than injecting it into the house. A lot of people put the responsibility of making a kitchen into the house, but have you ever seen a house which con build a kitchen, but I have seen a lot of house builders (aka sub-contractors) which know how to come in and build me one.

By: Al

Al — Wed, 26 Aug 2009 01:08:30 +0000

This is really based on experience, particularly with code that lasts several years (and therefore becomes a cash cow). It’s not just a matter of typing; it’s a question of encapsulation. And I see it as a conflict between a view unit testing and good object-oriented design.

For example, I may want to come out with a new, low-cost kind of house without a kitchen. I may want a new version of my app where the kitchen is optional, and is not created until the use clicks the “add kitchen” button and chooses the color. Or I may want to implement a new kind of kitchen and allow application logic to choose which one. These cases are examples of business rules, and really belong in the House class.

By: misko

misko — Fri, 10 Jul 2009 13:53:32 +0000

@al
is this your theory or actual experience? My expereince, especialy when using DI frameworks is that the code becomes much cleaner. Yes it is slightly more typing but the result is well worth it. Especialy from the maintainabilitypoint of view.