Mocking concrete class - Not recommended
- by Mik378
I've just read an excerpt of "Growing Object-Oriented Software" book which explains some reasons why mocking concrete class is not recommended.
Here some sample code of a unit-test for the MusicCentre class:
public class MusicCentreTest {
@Test public void startsCdPlayerAtTimeRequested() {
final MutableTime scheduledTime = new MutableTime();
CdPlayer player = new CdPlayer() {
@Override
public void scheduleToStartAt(Time startTime) {
scheduledTime.set(startTime);
}
}
MusicCentre centre = new MusicCentre(player);
centre.startMediaAt(LATER);
assertEquals(LATER, scheduledTime.get());
}
}
And his first explanation:
The problem with this approach is that it leaves the relationship
between the objects implicit. I hope we've made clear by now that the
intention of Test-Driven Development with Mock Objects is to discover
relationships between objects. If I subclass, there's nothing in the
domain code to make such a relationship visible, just methods on an
object. This makes it harder to see if the service that supports this
relationship might be relevant elsewhere and I'll have to do the
analysis again next time I work with the class.
I can't figure out exactly what he means when he says:
This makes it harder to see if the service that supports this
relationship might be relevant elsewhere and I'll have to do the
analysis again next time I work with the class.
I understand that the service corresponds to MusicCentre's method called startMediaAt.
What does he mean by "elsewhere"?
The complete excerpt is here:
http://www.mockobjects.com/2007/04/test-smell-mocking-concrete-classes.html
