2010-08-02 28 views
7

Sto sviluppando con Grails. Poiché il framework eseguirà il bootstrap dei dati e un contesto primaverile completamente svuotato, trovo che scrivo molti test di integrazione per i servizi. Lasciatemi riformulare quello: trovo che non scrivo test unitari per servizi, solo test di integrazione. È una cattiva idea? L'unico inconveniente che vedo è che i miei test richiedono un po 'più di tempo per essere eseguiti.Test di integrazione e unità

Uso i test delle unità sui controller, come in un controller sto testando i vari flussi applicativi, i tipi di risultati, la logica di reindirizzamento, ecc. Ma la maggior parte dei test che scrivo sono test di integrazione. Questa sembra una rottura rispetto ai tradizionali test J2EE, in cui vengono scritti principalmente test di unità.

modifica - per essere chiari, non sto scrivendo test di integrazione perché il codice è così complicato che solo i test di integrazione faranno. Sto scrivendo test di integrazione perché è più facile testare tutto insieme, dal momento che il framework ti dà tanto. Faccio schifo a certe cose, come se un servizio collabori con l'acegi authenticationService, lo sbeffo. Inoltre, simulo ogni volta che interagiamo con un webservice, perché è necessario per ottenere un test eseguito senza un'impostazione speciale.

+4

I test di integrazione possono essere più fragili dei test unitari. Se ti trovi a scrivere per lo più test di integrazione, prendi in considerazione il refactoring del tuo progetto in modo che possa essere sottoposto a test unitari più facilmente. Se il tuo codice è scritto, quindi è testabile, potresti scoprire che i test unitari sono più facili da scrivere rispetto ai test di integrazione e sono più stabili (meno adatti a interrompersi). I test di integrazione sono utili per testare le interazioni tra i componenti del sistema, ma non sempre forniscono una copertura del codice adeguata, quindi non sostituiscono i test unitari. –

risposta

11

Vedo chiaramente una tendenza verso test più funzionali e un numero inferiore di test unitari, in particolare per componenti fortemente collegati con poca logica. Se implemento un algoritmo complicato in una particolare classe, di solito scriverò dei test unitari, ma se la complessità è dovuta all'integrazione con altri componenti (che è molto frequente), i test unitari non valgono la pena.

0

Potrebbe essere possibile utilizzare una struttura di simulazione per isolare diverse parti dei servizi per i singoli test. Invece di fare affidamento sull'enorme contesto di Spring, creare direttamente un'istanza della classe di servizio e compilare le dipendenze non direttamente rilevanti per il test con i mock. Potresti aver bisogno di un piccolo refactoring per disaccoppiare le tue dipendenze, ma di solito sarà per il meglio. Questo può portare a scrivere più e più piccoli test invece di basarsi su alcuni test di integrazione di grandi dimensioni.

Sono in una situazione simile in cui molti test stabiliti sono davvero test di integrazione, e può essere difficile, ma non impossibile, cambiare in futuro.

2

In generale, la misura importante è la copertura del codice.

In può essere vantaggioso eseguire test di integrazione se l'interfaccia globale è più stabile (meno soggetto a modifiche).

0

Si consiglia di testare il prima possibile, perché si desidera visualizzare gli errori il più presto possibile, idealmente mentre il nostro codice è ancora sotto il proprio controllo. Più tardi si scopre un errore maggiore sarà il costo della correzione.

Se si espone una logica non banale, è necessario testare la logica dei principali percorsi decisionali con i test unitari e l'esposizione di tale logica e l'interazione con le dipendenze esterne nei test di integrazione.

Se sei uno sviluppatore solitario o lavori in un piccolo team, a volte è difficile vedere la distinzione tra test di unità e di integrazione. Se ti trovi in ​​un ambiente in cui più team lavorano su un singolo prodotto, l'ipotesi è che la logica all'interno del tuo codice sia già stata verificata (test unitario) e ora vuoi vedere come i moduli giocano tra loro (test di integrazione) .

Non è un buon esempio caricare troppo nel test di integrazione, perché si stanno rimandando i test in una fase successiva del progetto o dell'ambiente di sviluppo, e prima o poi si scoprirà che si stanno scoprendo errori una volta il codice ha lasciato la tua scrivania. Ciò significa mantenere l'intero e possibilmente la versione del prodotto mentre si aggiusta qualcosa che si potrebbe e dovrebbe avere scoperto in precedenza.

Problemi correlati