Вот сложный подход:
Одной из идей будет реализация шаблона Observer
, определение интерфейса слушателя, который может подписываться на события из вашего тестируемого класса.событие в этом случае будет отправлено после блока if:
public interface EventListener{
// EventDetails would be an object that encapsulates
// event type and extra data
void process(EventDetails type);
}
private void dispatchEvent(EventType type){
for(EventListener listener : this.listeners){
listener.process(new EventDetails(type
/* you'll want to add more data than that here */));
}
}
@Override
public void update() {
if (isStopped() || isPaused()) {
return;
}
dispatchEvent(EventType.UPDATE);
// ...
}
И в классе тестирования:
yourClass.addEventListener(new EventListener(){
public void process(EventDetails details){
if(EventType.UPDATE.equals(details.getEventType())){
fail("Received update event");
}
}
});
// set to stopped or paused
yourClass.update();
// if we got here, test has succeeded
Конечно, этот подход является огромным вмешательством в то, как все происходит.работает сейчас, и это имеет смысл только в том случае, если ваше приложение действительно может использовать систему уведомлений о событиях (возможность модульного тестирования является хорошим побочным эффектом).
Или что-то совершенно другое:
в модульном тесте используйте подкласс, который переопределяет любой метод, вызываемый после блока if.
Итак, предположим, что оригинальный код такой:
@Override
public void update() {
if (isStopped() || isPaused()) {
return;
}
doUpdate();
}
тогда подкласс переопределитdoUpdate()
метод:
protected void doUpdate(){
fail("I shouldn't be here");
}