views:

91

answers:

2

I have a Carpenter class that does it's work using a Lathe and a Wood object.

class Carpenter
{
 function Work()
 {
  $tool = new Lathe();
  $material = new Wood();
  $tool->Apply($material);
 }
}

Lathe depends on an interface called Material, so I can easily unit test Lathe by giving it a fake Material in my unit test. Wood doesn't depend on anything, so it can also be easily tested.

interface Material {
 // Various methods...
}

interface Tool {
 function Apply(Material $m);
}

class Wood implements Material {
    // Implementations of Material methods
}

class Lathe {
 function Apply(Material $m) {
  // Do processing
 }
}

However, Carpenter depends on the concrete classes Lathe and Wood because it has to create instances of them. That means that as it currently stands, I cannot unit test the Work() method without inadvertantly bringing Lathe and Wood under test.

How should I change my design to unit test Carpenter?

+2  A: 

The key is to seperate object creation from object use in Carpenter.

class Carpenter
{
 function getTool() {
  return new Lathe();
 }
 function getMaterial() {
  return new Wood();
 }
 function Work()
 {
  $tool = getTool();
  $material = getMaterial();
  $tool->Apply($material);
 }
}

That way you can override the getTool() and getMaterial() methods in a TestCarpenter class and inject your own Material and Tool fakes.

The getTool() and getMaterial() methods can also be unit tested seperately.

Michael Feathers would call the getTool() and getMaterial() methods "seams", because they are points where fakes can be inserted without changing the surrounding code.

ctford
+3  A: 

There's a couple of different directions you can take here:

  • Use Constructor Injection and simply inject the tool and the material instances into the carpeter.
  • If injecting instances doesn't work for some reason (perhaps because you need to create new instances for every invocation of the Work method), you can inject Abstract Factories instead.
  • You can also use the Factory Method approach described by ctford, but that requires you to also create test-specific overrides to be able to unit test, and while that's a completely valid thing to do, it's just more work and in many cases the other alternatives are better and more flexible.
Mark Seemann
Interesting. But if you inject an Abstract Factory, aren't you just shifting the unit testing problem to the method that creates the Abstract Factory and injects it into the Carpenter? Thanks for your help.
ctford
No, because using an Abstract Factory decouples object creation from behavior, which means you can unit test each in isotaion.
Mark Seemann
You can unit test the Abstract Factory itself, but the method that creates the Abstract Factory and then feeds it to a Carpenter will have the same issues as in the original question. You'd have to figure out a way to inject a Testing Abstract Factory into that method (and I don't think an Abstract Factory Factory would be the way to go :) ... right?
ctford
An Abstract Factory or any other dependency can (and normally should) be injected through the constructor (Constructor Injection). It will be responsibility of the caller to provide the correct factory.
Mark Seemann