Separazione delle classi JUnit in un pacchetto di test speciale?

Sto imparando i concetti dello sviluppo basato sui test leggendo gli articoli di Craftsman (fare clic su Craftsman in By Topic ) consigliati in una risposta alla mia domanda precedente, "Progetto di esempio per l'apprendimento di JUnit e dell'ingegneria del software adeguata" . Lo adoro finora!

Ma ora voglio sedermi e provare io stesso. Ho una domanda che spero richieda solo una semplice risposta.

Come organizzi le tue classi di test JUnit e il tuo codice effettivo? Sto parlando principalmente della struttura del pacchetto, ma anche qualsiasi altro concetto degno di nota sarebbe utile.

Metti le classi di test in org.myname.project.test. * E il codice normale in org.myname.project. *? Metti le classi di prova accanto alle classi normali? Preferisci anteporre ai nomi delle classi Test piuttosto che aggiungerli come suffisso?

So che questo sembra il genere di cose di cui non dovrei preoccuparmi così presto, ma sono una persona molto incentrata sull'organizzazione. Sono quasi il tipo di persona che passa più tempo a trovare metodi per tenere traccia di cosa fare, piuttosto che a portare a termine le cose.

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

modifica: mi sono completamente dimenticato di Maven, ma sembra che la maggior parte di voi lo stia usando! In passato ho avuto un caso d'uso specifico in cui Maven si è completamente rotto su di me, ma Ant mi ha dato la flessibilità di cui avevo bisogno, quindi sono finito per attaccarmi ad Ant, ma penso che forse stavo solo prendendo l'approccio sbagliato. Penso che darò a Maven un altro tentativo perché sembra che andrà bene con lo sviluppo basato sui test.

Preferisco mettere le classi di test nello stesso pacchetto delle classi di progetto che testano, ma in una directory fisica diversa, come:

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

In un progetto Maven sarebbe simile a questo:

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 dell'ambito del pacchetto.

Come mostra l'esempio sopra, le mie classi di test hanno il nome della classe testata più Testcome suffisso. Questo aiuta a trovarli rapidamente: non è molto divertente provare a cercare tra un paio di centinaia di classi di test, ognuna del cui nome inizia con Test...

Aggiornamento ispirato al commento di @ Ricket: in questo modo le classi di test (in genere) vengono visualizzate subito dopo il loro compagno testato in un elenco alfabetico dei nomi delle classi in base al progetto. (Divertente che io stia beneficiando di questo giorno dopo giorno, senza aver consapevolmente realizzato come ...)

Update2: molti sviluppatori (me compreso) amano Maven, ma sembra che ce ne siano almeno altrettanti che non lo fanno. IMHO è molto utile per i 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 possono accettare le convenzioni di Maven; tuttavia, in caso contrario, rende la vita una lotta miserabile. Maven sembra essere difficile da comprendere per molte persone socializzate su Ant, poiché a quanto pare richiede un modo di pensare molto diverso. (Io stesso, non avendo mai usato Ant, non posso confrontare i due.) Una cosa è certa: rende il test di unità (e integrazione) un passo naturale e di prima classe nel processo, che aiuta gli sviluppatori ad adottare questa pratica essenziale.

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

Uso Maven . La struttura che Maven promuove è: -

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

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

cioè una classe di test con Test anteposto al nome della classe sotto test si trova in una struttura di directory parallela al test principale.

Un vantaggio di avere le classi di test nello stesso pacchetto (non necessariamente directory) è che puoi sfruttare i metodi dell'ambito del pacchetto per ispezionare o iniettare oggetti di test fittizi.