Ho appena letto un estratto del libro "Growing Object-Oriented Software" che spiega alcuni motivi per cui il mocking della classe concreta non è raccomandato.
Ecco alcuni esempi di codice di un test unitario per la classe MusicCentre:
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());
}
}
E la sua prima spiegazione:
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.
Non riesco a capire esattamente cosa intende quando dice:
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.
Capisco che il servizio corrisponda al metodo di MusicCentre chiamato startMediaAt .
Che cosa intende con "altrove"?
L'estratto completo è qui: link