Dove devo mettere i miei test JUnit?

Question

Ho 2 domande sull'organizzazione dei test unitari.

1. Devo mettere test nello stesso pacchetto della classe testata o posso organizzare i test in pacchetti diversi?

   Ad esempio se ho validità e altri test, è corretto dividerli in pacchetti diversi, anche se sono per la stessa classe?

2. Che dire delle classi finte e stub? Devo separarli dai pacchetti contenenti solo test o metterli insieme?

Answer 1

Il modo in cui eseguiamo i nostri casi di test JUnit consiste nel metterli nello stesso pacchetto, ma in una directory root diversa. Dato che utilizziamo Maven, utilizziamo solo le posizioni standard rendendo la struttura simile alla seguente.

src/main/java/com/foo/Bar.java
src/test/java/com/foo/BarTest.java

Ovviamente c'è di più nella struttura, ma questo ci permette di costruire i test separatamente dal codice mainline, ma comunque accedere a classi protette e simili. Per quanto riguarda i diversi tipi di test, questo è molto soggettivo. Quando abbiamo iniziato il nostro sforzo di test (che purtroppo è iniziato dopo lo sviluppo), ho cercato di mantenere le cose piuttosto isolate. Sfortunatamente, divenne rapidamente un incubo quando arrivammo al punto 500+ del test case. Da allora ho provato a fare più consolidamento. Ciò ha portato a una riduzione delle quantità di codice da mantenere. Come ho detto, però, è molto soggettivo.

Per quanto riguarda il codice di solo test, lo conserviamo in un pacchetto com.foo.test separato che risiede solo nell'albero src / test / java .

Answer 2

Anch'io tendo a mettere i miei test nello stesso pacchetto ma in una directory root diversa. Questo mi permette di testare classi private-pacchetto o accedere a classi private-pack mentre collaudo qualcos'altro nel pacchetto. Vengono conservati in un albero di directory separato per consentire di escluderli dal risultato distribuito (in particolare per garantire che il codice di test non venga accidentalmente inserito nel codice di produzione). Ciò che conta di più, tuttavia, è ciò che funziona per la tua situazione.

In termini di quante classi di test per classe di produzione, la teoria che ho visto è che si scrive una classe di test per dispositivo, cioè per struttura di installazione. In molti casi è lo stesso (o abbastanza vicino) a una classe di test per classe di produzione, ma a volte ho scritto più classi di test (in particolare i test di uguaglianza tendono a essere separati) per una classe di produzione, e occasionalmente una classe di test di per un gruppo di (correlate) classi di produzione (ad esempio, per testare il modello di strategia).

Principalmente, non mi preoccupo troppo della teoria, ma rielaboro i test secondo necessità per mantenere la duplicazione al minimo assoluto.

Answer 3

Le classi di test dovrebbero essere piuttosto in pacchetti diversi, è più facile separarle dal codice di produzione quando lo si impacchetta per il rilascio. Di solito tengo un sacco di test di lanugine in quei pacchetti, tutti i tipi di simulazioni, configurazioni, scenari .. Ma quando costruisci, non lo capisco. In alcune situazioni, è una buona idea mantenere le tue prove anche in diversi progetti. Dipende.

Answer 4

Mantenere lo stesso pacchetto consente di utilizzare la visibilità pacchetto-privata per il codice a cui si desidera accedere solo tramite il test.

Per quanto riguarda l'utilizzo di directory root separate, questa è una buona pratica. Ha anche un vantaggio per noi, poiché utilizziamo IDEA, IDEA riconosce che il codice di produzione non può fare riferimento al codice di prova.

In termini di tenerli separati, c'è una grande potenza nell'avere una, e solo una, classe di test per classe di produzione a livello di unità. Naturalmente, alcune classi vengono create in produzione come parte del refactoring che non hanno affatto classi di test, e questo va bene, ma quando vuoi sapere quale test verifica una determinata classe, avere una convenzione che dice ClassNameTest è il test per ClassName è molto utile.

TestNG è molto più amichevole con questo paradigma di JUnit, tuttavia.