Trennung von JUnit-Klassen in spezielles Testpaket?

Question

ich die Konzepte der Testgetriebene Entwicklung durch das Lesen der in einer Antwort auf meine vorherige Frage empfohlen Craftsman articles (klicken Craftsman unter By Topic) Lernen, "Sample project for learning JUnit and proper software engineering". Ich liebe es so weit!

Aber jetzt möchte ich mich hinsetzen und es selbst ausprobieren. Ich habe eine Frage, von der ich hoffe, dass sie nur eine einfache Antwort braucht.

Wie organisieren Sie Ihre JUnit-Testklassen und Ihren tatsächlichen Code? Ich spreche hauptsächlich über die Paketstruktur, aber alle anderen Konzepte der Notiz wäre auch hilfreich.

Setzen Sie Testklassen in org.myname.project.test. * Und normalen Code in org.myname.project. *? Legen Sie die Testklassen neben die normalen Klassen? Bevorzugen Sie den Klassennamen lieber Test als Suffix?

Ich weiß, das scheint die Art von Sache zu sein, über die ich mir so schnell keine Sorgen machen sollte, aber ich bin eine sehr organisationszentrierte Person. Ich bin fast die Art von Person, die mehr Zeit ausgibt, Methoden herauszufinden, um zu verfolgen, was getan werden soll, anstatt tatsächlich Dinge zu erledigen.

Und ich habe ein Projekt, das derzeit ordentlich in Pakete aufgeteilt ist, aber das Projekt wurde ein Durcheinander. Anstatt zu versuchen, alles neu zu gestalten und Tests zu schreiben, möchte ich zuerst mit allen Tests beginnen. Aber zuerst muss ich wissen, wo meine Tests hingehen.

---

edit: Ich hatte total vergessen, über Maven, aber es scheint eine Mehrheit der Sie es verwenden! In der Vergangenheit hatte ich einen speziellen Anwendungsfall, bei dem Maven völlig zusammenbrach, aber Ant gab mir die Flexibilität, die ich brauchte, und so endete ich bei Ant, aber ich dachte, dass ich vielleicht nur den falschen Weg nahm. Ich denke, ich werde Maven noch einen Versuch geben, weil es so klingt, als würde es gut mit testgetriebener Entwicklung laufen.

Answer 1

Ich ziehe setze die Testklassen in das gleiche Paket wie die Projektklassen sie testen, aber in einem anderen physischen Verzeichnis, wie:

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

In einem Maven Projekt würde es so aussehen:

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

Der Hauptpunkt in diesem ist, dass meine Testklassen auf Package-Scope Klassen und Mitglieder zugreifen können (und testen!). Wie das obige Beispiel zeigt, haben meine Testklassen den Namen der getesteten Klasse plus Test als Suffix.Dies hilft ihnen, schnell zu finden - es ist nicht sehr lustig ist unter ein paar hundert Testklassen zu versuchen, die Suche, die jeweils deren Name beginnt mit Test ...

aktualisieren inspiriert von @ Rickets Kommentar: auf diese Weise Testklassen (typischerweise) erscheinen direkt nach ihrem getesteten Buddy in einer projektweisen alphabetischen Auflistung von Klassennamen. (Komisch, dass ich von diesem Tag für Tag bin profitieren, ohne bewusst realisiert zu haben, wie ...)

Update2: Viele Entwickler (mich eingeschlossen) wie Maven, aber es scheint zumindest so viele zu sein, nicht. IMHO ist es sehr nützlich für "mainstream" Java-Projekte (ich würde etwa 90% der Projekte in diese Kategorie stellen ... aber die anderen 10% sind immer noch eine beträchtliche Minderheit). Es ist einfach zu verwenden, wenn man die Maven-Konventionen akzeptieren kann; wenn nicht, macht es das Leben zu einem erbärmlichen Kampf. Maven scheint für viele Leute, die auf Ant vergesellschaftet sind, schwer zu verstehen, da es offensichtlich eine ganz andere Art des Denkens erfordert. (Da ich Ant nie benutzt habe, kann ich die beiden nicht vergleichen.) Eines ist sicher: Es macht Unit (und Integration) Testing zu einem natürlichen, erstklassigen Schritt in diesem Prozess, der Entwicklern hilft, diese essenzielle Praxis anzuwenden.

Answer 2

Ich verwende Maven. Die Struktur, die Maven fördern, ist: -

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

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

das heißt eine Testklasse mit Test zum Namen der Klasse unter Test vorangestellt ist in einer parallelen Verzeichnisstruktur die Hauptprüfung.

Ein Vorteil der Verwendung der Testklassen im selben Paket (nicht unbedingt im Verzeichnis) besteht jedoch darin, dass Sie mithilfe von Package-Scope-Methoden Mock-Testobjekte untersuchen oder injizieren können.

Answer 3

Ich legte meine Testklassen in das gleiche Paket wie sie testen aber in einem anderen Quellordner oder Projekt. Indem ich meinen Testcode auf diese Weise organisiere, kann ich ihn einfach kompilieren und separat verpacken, so dass die Produktions-JAR-Dateien keinen Testcode enthalten. Außerdem kann der Testcode auf private Felder und Methoden des Pakets zugreifen.