Devo separare i test unitari e i test di integrazione?

Devo scrivere unit test e test di integrazione per un progetto.

Tutti i test devono essere inseriti in una singola cartella dei test ?
O i test unitari e i test di integrazione dovrebbero essere ciascuno in una cartella test separata ?
O dovrei anche metterli in progetti separati ?

Se li tengo insieme, ci sono vantaggi o svantaggi con questo approccio?

architecture unit-testing integration-tests

— Ahmed Ragheb
fonte

Se si opera in un ambiente CI, l'importante è che possano essere facilmente identificati (per attributo, ecc.) Poiché i test di integrazione non vengono sempre eseguiti sul server di compilazione.

— Robbie Dee,

Correlati: Test: unità vs. integrazione vs. altri, qual è il bisogno di separazione?

— mouviciel,

In generale: sì, è necessario inserire i test di integrazione e i test unitari in cartelle diverse. Spesso i programmatori non tracciano una linea chiara tra questi due tipi di test e scrivono semplicemente qualsiasi tipo di test sia utile. Ma i test di integrazione tendono ad essere più lenti, perché spesso coinvolgono:

Domande sul database
Richieste di rete
Comportamento dipendente dal tempo
Grandi quantità di dati

Al contrario, un test di unità deriderebbe qualsiasi operazione costosa, quindi i test di unità tendono a essere eseguiti rapidamente (in effetti, la parte più lenta dell'esecuzione del test è spesso il framework di test stesso).

Quando un programmatore sta lavorando sul sistema, si trova in un ciclo di modifica-test. Più velocemente ottengono feedback sui test e più breve è il ciclo, più produttivi possono essere. Quindi lì vogliamo solo eseguire test importanti che si completano rapidamente. La suite di test completa verrebbe eseguita solo come parte di un processo di controllo qualità, ad esempio su un server CI.

Ciò significa che le grandi suite di test dovrebbero essere classificate. Possiamo selezionare solo unit test per un particolare componente? Possiamo escludere test lenti? Un modo semplice per farlo è mantenere diverse suite di test in diverse directory. Se hai solo pochissimi test, anche una singola directory andrebbe bene finché un programmatore può facilmente selezionare un sottoinsieme di test.

Tutto ciò che consente a un programmatore di ricevere rapidamente feedback è positivo. La suite di test più completa non ha importanza se non viene eseguita regolarmente.

Ulteriori letture:

Test: unità vs. integrazione vs. altri, qual è il bisogno di separazione? che era collegato da mouviciel sopra.
Devo separare i test unitari dai test di integrazione? sul mio blog, che discute questa risposta in modo un po 'più dettagliato.

— amon
fonte

Quando si separano le cartelle, le conservate tutte nello stesso pacchetto del codice di produzione (in modo da poter testare i metodi protetti)? Esempio, si crea un modulo maven per i test unitari e un altro modulo maven per i test di integrazione. In questo modo, puoi separarli e comunque testare facilmente i metodi protetti.

— ihebiheb,

@ihebiheb In Java, l'utilizzo della visibilità del pacchetto è piuttosto disapprovato. In alcuni casi può essere utile utilizzarlo e accedere a queste API dai test unitari. Ma in generale, non è necessario. I test in stile integrazione non hanno mai bisogno dell'accesso ai membri privati del pacchetto. L'opportunità o meno di inserire i test in un progetto Maven separato dipende da come si desidera eseguirli e distribuirli. Non mi piace Java / Maven per poterti dire cosa è sensato qui.

— amon