Separazione delle classi JUnit in un pacchetto di test speciale?

Question

Sto imparando i concetti di Test-Driven Development attraverso la lettura del Craftsman articles (clicca Artigiano sotto per argomento) raccomandato in una risposta alla mia domanda precedente, "Sample project for learning JUnit and proper software engineering". Mi piace così tanto!

Ma ora voglio sedermi e provarlo da solo. Ho una domanda che spero abbia bisogno solo di una semplice risposta.

Come organizzare le classi di test JUnit e il codice effettivo? Sto parlando principalmente della struttura del pacchetto, ma anche altri concetti di nota potrebbero essere utili.

Inserisci le classi di test in org.myname.project.test. * E il codice normale in org.myname.project. *? Metti le classi di test direttamente accanto alle classi normali? Preferisci anteporre i nomi delle classi a Test piuttosto che suffissarli?

So che questo sembra il tipo di cosa di cui non dovrei preoccuparmi così presto, ma sono una persona molto organizzativa. Sono quasi il il tipo di persona che trascorre più tempo a capire i metodi per tenere traccia di cosa fare, piuttosto che fare le cose.

E ho un progetto che è attualmente suddiviso in pacchetti, ma il progetto è diventato un casino. Invece di cercare di refactoring tutto e scrivere test, voglio ricominciare da capo, i test prima e tutto. Ma prima devo sapere dove vanno i miei test.

---

edit: ho completamente dimenticato Maven, ma sembra una maggioranza di che lo si utilizza! In passato avevo un caso d'uso specifico in cui Maven si era completamente abbattuto su di me, ma Ant mi ha dato la flessibilità di cui avevo bisogno, quindi sono finito attaccato ad Ant, ma sto pensando che forse stavo prendendo l'approccio sbagliato. Penso che darò un'altra prova a Maven perché sembra che andrà bene con lo sviluppo basato sui test.

Answer 1

preferisco mettere le classi di test nello stesso pacchetto come categoria di progetti che mettono alla prova, ma in una directory fisica differente, come:

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

In un progetto Maven sarebbe simile a questa:

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

Il punto principale in questo è che le mie classi di test possono accedere (e testare!) Classi e membri del pacchetto.

Come nell'esempio precedente, le mie classi di test hanno il nome della classe testata più Test come suffisso.Questo aiuta a trovare rapidamente - non è molto divertente di provare a cercare tra un paio di centinaia di classi di test, ognuno dei cui nome inizia con Test ...

Aggiornamento ispirato @ di Ricket commento: in questo modo classi di test (di solito) si presentano subito dopo il loro amico collaudato in un elenco alfabetico di nomi di classi in base al progetto. (Divertente che sto traendo beneficio da questo giorno per giorno, senza aver realizzato consapevolmente come ...)

Update2: Un sacco di sviluppatori (me compreso) come Maven, ma sembra che ci sia almeno altrettanti che non lo fanno. IMHO è molto utile per progetti Java "mainstream" (metterei circa il 90% dei progetti in questa categoria ... ma l'altro 10% è ancora una minoranza considerevole). È facile da usare se si accettano le convenzioni Maven; tuttavia se non, rende la vita una lotta miserabile. Sembra che Maven sia difficile da comprendere per molte persone socializzate su Ant, dal momento che apparentemente richiede un modo di pensare molto diverso. (Io stesso, non avendo mai usato Ant, non posso paragonare i due.) Una cosa è certa: rende l'unità (e l'integrazione) testando un passaggio naturale di prima classe nel processo, che aiuta gli sviluppatori ad adottare questa pratica essenziale.

Answer 2

Io uso Maven. La struttura che promuove Maven è: -

src/main/java/org/myname/project/MyClass.java 

src/test/java/org/myname/project/TestMyClass.java 

vale a dire una classe di test con Test anteposto al nome della classe in prova è in una struttura di directory parallela alla prova principale.

Un vantaggio di avere le classi di test nello stesso pacchetto (non necessariamente la directory) è che è possibile sfruttare i metodi del pacchetto per esaminare o iniettare oggetti di prova fittizi.

Answer 3

Ho inserito le mie classi di test nello stesso pacchetto di quello che stanno testando ma in un'altra cartella di origine o nel progetto. Organizzare il mio codice di test in questo modo mi consente di compilarlo e confezionarlo facilmente separatamente in modo che i file jar di produzione non contengano il codice di test. Consente inoltre al codice di test di accedere ai campi e ai metodi privati ​​del pacchetto.