Я щойно прочитав уривок книги "Зростаюче об'єктно-орієнтоване програмне забезпечення", в якій пояснюються деякі причини, чому знущатися з конкретного класу не рекомендується.
Ось приклад коду одиничного тесту для класу 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());
}
}
І його перше пояснення:
Проблема такого підходу полягає в тому, що він залишає стосунки між об'єктами неявними. Я сподіваюсь, що до цього часу ми зрозуміли, що метою тестової розробки з об'єктами макету є виявлення зв’язків між об'єктами. Якщо я підкласу, у доменному коді немає нічого, щоб зробити таке співвідношення видимим, просто методи на об'єкті. Це ускладнює переконання, чи може служба, яка підтримує цей зв'язок, доречна в іншому місці, і мені доведеться робити аналіз ще раз, коли я працюю з класом.
Я не можу точно зрозуміти, що він має на увазі, коли каже:
Це ускладнює переконання, чи може служба, яка підтримує цей зв'язок, доречна в іншому місці, і мені доведеться робити аналіз ще раз, коли я працюю з класом.
Я розумію, що сервіс відповідає MusicCentre
методу 'call' startMediaAt
.
Що він має на увазі під «іншим місцем»?
Повний витяг тут: http://www.mockobjects.com/2007/04/test-smell-mocking-concrete-classes.html