Test unitari con Mockito

Question

Scrivo test di unità per livello di servizio nella mia applicazione di molla.
Qui è la mia classe di servizio

@Service 
    public class StubRequestService implements RequestService {  
     @Autowired 
     private RequestDao requestDao; 

     @Transactional(propagation = Propagation.REQUIRED, readOnly = true) 
     @Override 
     public Request getRequest(Long RequestId) { 
      Request dataRequest = requestDao.find(requestId); 
      return dataRequest; 
     } 
    } 

Qui è la mia classe di test

@RunWith(MockitoJUnitRunner.class) 
@ContextConfiguration(locations = { "/META-INF/spring/applicationContext.xml" }) 
public class StubRequestServiceTest { 

    @Mock 
    public RequestDao requestDao; 

    StubRequestService stubRequestService; // How can we Autowire this ? 

    @org.junit.Before 
    public void init() { 
     stubRequestService = new StubRequestService(); // to avoid this 
     stubRequestService.setRequestDao(dataRequestDao); 
     // Is it necessary to explicitly set all autowired elements ? 
     // If I comment/remove above setter then I get nullPointerException 
    } 

    @Test 
    public void testGetRequest() { 
     Request request = new Request(); 
     request.setPatientCnt("3"); 
     when(requestDao.find(anyLong())).thenReturn(request); 
     assertEquals(stubRequestService.getRequest(1234L).getPatientCnt(),3); 
    }  
} 

il suo bel lavoro, ma ho alcune domande

1. Come possiamo Autowire classe di servizio in test? Sto usando il costruttore nel metodo init() per creare l'oggetto servizio.
2. Dobbiamo impostare tutto l'elemento Autowire per la classe di servizio? Per l'ex StubRequestService è stato attivato automaticamente RequestDao che ho bisogno di impostare in modo esplicito prima di chiamare il metodo di prova altrimenti ha dato nullPointerException come requestDao è null nel metodo StubRequestService.getRequest.
3. Quali sono le buone pratiche da seguire durante il collaudo unitario del livello di servizio Spring? (Se sto facendo qualcosa di sbagliato).

Answer 1

1. Se ritieni che renderà i tuoi test più facili da capire, puoi inizializzare un contesto primaverile e recuperare tutti gli oggetti da lì. Tuttavia, di solito è necessario creare un file XML di configurazione a molla separato specifico per i test, quindi non lo consiglierei.

   ApplicationContext applicationContext = new ClassPathXmlApplicationContext("testApplicationContext.xml"); 
   stubRequestService = (RequestService)applicationContext.getBean("myRequestServiceBean"); 
   

2. (e 3) In sostanza, io preferisco testare ogni componente della mia applicazione in totale isolamento l'uno dall'altro ed è per questo io non consiglio quello che ho descritto in [1].

Ciò significa, è si prende una fetta logica separata della vostra applicazione e prova solo, mentre completamente beffardo ogni cosa si prova ad accedere.

Diciamo che avere tre classi:

//Fetches stuff from some webservice and converts to your app domain POJOs 
class DataAccessLayer { 
    public void setWebservice(Webservice ws) {...}; 

    public MyObject getMyObject() {...}; 
} 

//Formats the domain POJOs and sends them to some kind of outputstream or stuff. 
class ViewLayer { 
    public void setOutputStream(OutputStream os) {...}; 

    public void viewMyObject(MyObject mo) {...}; 
} 

//Main entry point of our MyObject fetch-process-display workflow 
class Controller { 
    public void setDataAccessLayer(DataAccessLayer dal) {...}; 
    public void setViewLayer(ViewLayer vl) {...}; 

    public void showMyObject() { 
     MyObject mo = dal.getMyObject(); 
     ...some processing here maybe... 
     vl.viewMyObject(mo); 
    } 
} 

Ora, quali test possiamo scrivere qui?

1. prova se DataAccessLayer converte correttamente l'oggetto da deriso fino WS al nostro oggetto di dominio.
2. Test se ViewLayer formatta correttamente l'oggetto a lui assegnato e lo scrive su simulato sullo stream di output.
3. prova se Controller prende un oggetto dal deriso finoDataAccessLayer processi in modo corretto e lo invia al deriso finoViewLayer.

Answer 2

Il test è a posto. Non ha nemmeno bisogno di avere l'annotazione @ContextConfiguration.

L'intero concetto di framework di distribuzione delle dipendenze, come Spring, deve essere in grado di riunire i servizi di test semplicemente istanziandoli, impostando false dipendenze e quindi chiamando i loro metodi.

Lo stai facendo correttamente. Non è necessario disporre di un contesto di primavera per tali test unitari. Ecco perché sono chiamati unit test: lo testano in isolamento di tutte le loro dipendenze reali, inclusa la primavera.

Nota a margine: presupponendo che si stia utilizzando JUnit, gli argomenti del metodo assertXxx devono essere invertiti. Il valore previsto viene prima del valore effettivo. Diventa importante quando l'asserzione fallisce e hai un messaggio tipo "aspettarti 6 ma era 3" invece di "aspettarti 3 ma era 6".

Answer 3

oppure è possibile utilizzare springockito https://bitbucket.org/kubek2k/springockito/wiki/Home, che renderà il vostro test più pulita