MockMvc di Spring è utilizzato per test di unità o test di integrazione?

Question

Primavera ha 2 messe a punto per l'MockMvc:

1. configurazione standalone
2. configurazione WebApplicationContext

In generale che tipo di test viene utilizzato per MockMvc? Unità o integrazione? o entrambi?

Ho ragione nel dire che l'utilizzo della configurazione standalone (in esecuzione fuori dal contesto dell'applicazione Spring) consente di scrivere test di unità e con l'installazione WebApplicationContext è possibile scrivere test di integrazione?

Answer 1

Entrambe le forme sono in realtà test di integrazione poiché si sta testando l'integrazione del proprio codice con Spring DispatcherServlet e l'infrastruttura di supporto. La differenza sta nella quantità di infrastrutture di supporto utilizzate dietro le quinte.

I dettagli sono documentati nel manuale di riferimento Spring.

• Server-Side Tests
• Setup Options
• Difference With End-to-End Integration Tests

estratti Notevoli:

Il "webAppContextSetup" carica la configurazione effettiva Spring MVC risultante in un test di integrazione più completa. Poiché il framework TestContext memorizza nella cache la configurazione Spring caricata, aiuta a mantenere i test correndo velocemente anche se vengono aggiunti altri test. Inoltre, è possibile eseguire servizi di iniezione in controller tramite la configurazione di Spring, in ordine per rimanere focalizzati sulla verifica del livello Web.

...

Il "standaloneSetup" d'altra parte è un po 'più vicino ad un'unità prova. Mette alla prova un controller alla volta, il controller può essere iniettato manualmente con le dipendenze fittizie e non prevede il caricamento della configurazione Spring da Spring. Tali test sono più mirati nello stile e rendono più semplice vedere quale controller è in fase di test, se è necessaria una specifica configurazione MVC di Spring e così via.Il "standaloneSetup" è anche un modo molto conveniente per scrivere test ad-hoc per verificare un comportamento o per eseguire il debug di un problema.

...

Proprio come con l'integrazione vs unit test, non c'è giusto o sbagliato risposta. L'uso di "standaloneSetup" implica la necessità di alcuni test "webAppContextSetup" aggiuntivi per verificare la configurazione di Spring MVC . In alternativa, è possibile decidere di scrivere tutti i test con "webAppContextSetup" e verificare sempre la configurazione effettiva di Spring MVC .

...

Le opzioni fornite in Spring MVC test sono diverse fermate sulla scala dall'unità classico al test di integrazione piena. Per essere sicuro che nessuno di le opzioni in Spring MVC Test sono test di unità classiche, ma sono un un po 'più vicino ad esso. Ad esempio è possibile isolare il livello di servizio con i mock iniettati nei controller e quindi testare il livello Web solo tramite DispatcherServlet e con la configurazione Spring effettiva, proprio come si potrebbe verificare il livello del database nell'isolamento dei layer sopra . Oppure potresti utilizzare la configurazione standalone concentrandosi su un controller alla volta e fornendo manualmente la configurazione necessaria per farlo funzionare.

In caso di dubbio, suggerisco di leggere prima il manuale di riferimento prima di inviare domande qui. ;)

saluti,

Sam (autore della primavera TestContext quadro)

Answer 2

Direi che entrambi i metodi sono per i test di integrazione, ma standalone ti obbligano a specificare quale controller stai testando.

L'installazione WebApplicationContext sta caricando l'intero contesto, quindi non ti interessa dove è il controller specifico che serve, ad esempio, le richieste POST /people.

Quindi mi consiglia di utilizzare l'installazione WebApplicationContext per testare l'API REST in termini di interfaccia con cui l'applicazione deve lavorare. Non accoppiare test con codice effettivo, quindi + stai documentando il modo in cui l'app dovrebbe comportarsi.