Utilizzo di easymock nel multithreading

Question

Voglio verificare che alcuni metodi vengano richiamati in caso di errori. Chiamata eseguita in thread separati. Così scrivo codice come questo

final Foo mock = createStrictMock(Foo.class); 

mock.bar(); 
expectLastCall().andThrow(new RuntimeException("TEST EXCEPTION")); 
mock.bar(); 
replay(mock); 

doStuff(); 
sleepSomeTime(); //Pretty dirty. But I need to test it in multithreading. 
verify(mock); 

E test superato. Ma non ho ancora implementato il richiamo.

Per effettuare test di fallire, ho sostituito

mock.bar(); 
expectLastCall().andThrow(new RuntimeException("TEST EXCEPTION")); 

con

mock.bar(); 
expectLastCall().andAnswer(new IAnswer<Void>() { 
     @Override 
     public Void answer() throws Throwable { 
      sleepSomeTime(); 
      throw new RuntimeException("TEST EXCEPTION"); 
     } 
    }); 

Ma non mi piace l'aggiunta di sleepSomeTime tutto intorno i miei test. Oltre a ciò, in realtà non capisco mentre aiuta in questo caso particolare. Quindi,

Perché aggiungere ritardo è stato utile?

Quale è il modo giusto per fare queste cose?

Answer 1

Il mio approccio è stato quello di utilizzare le serrature. Non c'è abbastanza informazioni nel tuo post per mostrare qualcosa di definitivo, ma sarebbe probabilmente cercare qualcosa di simile:

final Lock lock = new Lock(); 
lock.lock(); 
expectLastCall().andAnswer(new IAnswer<Void>() { 
    @Override public Void answer() throws Throwable { 
     lock.unlock(); 
     throw new RuntimeException("TEST EXCEPTION"); 
    } 
});  
doStuff(); 
lock.lock(); 
verify(mock); 

Il succo qui è la seconda serratura() chiamata è bloccata fino a quando lo sblocco nel vostro finto libera la serratura.

Answer 2

Hai provato a implementare utilizzando lavoratori swing?

anche ciò che si potrebbe desiderare di provare è se si è in attesa allora si potrebbe desiderare di provare ed utilizzare notify o utilizzando una classe synchronized.

Answer 3

Non esiste un modo semplice per eseguire il test dell'unità in un contesto multi-thread.

Ma ti suggerisco di leggere questo answer to another similar question. Il DRTestUtils fornisce alcuni metodi convenienti a nasconde il Thread.sleep dietro una chiamata di metodo più bella waitForCondition.