Wieso sind eigentlich JUnit-Tests in src/test/java platziert - nur Konvention?

[Zrebna]

Hi!
Frage steht ja schon im Titel - ist das nur Konvention, dass man Unit-Tests in einem Maven-Projekt im src/test/java-Verzeichnis platziert, oder hat das handfeste Gründe, Vorteile oder gar Notwendigkeiten?

Erleichtert oder ermöglicht diese Platzierung z.B. die Integration in eine CI-Pipeline? Oder vereinfacht es den Build-Prozess in Maven, wenn man Uint-Tests automatisiert ausführt?

Oder ist das alles egal und es würde genauso alles gut funktionieren, wenn man Unit-Tests sturr in ein eigenes Maven-(Unter)-Projekt packt, sodass es letztlich eben nur Konventio ist?

Lg
Zrebna

 

[KonradN]

Das ist eine Konvention, die in Maven einmal festgelegt wurde. Dies kannst Du z.B. in der Super POM erkennen:
Super POM (apache.org)
Dort siehst du dann in build die Festlegung testSourceDirectory:
<testSourceDirectory>${project.basedir}/src/test/java</testSourceDirectory>

Und ja - das könntest Du einfach umändern. Setz einfach testSourceDirectory in Deiner POM und schon liegt es woanders.

Wenn Du einen guten Grund hast, dann kannst Du es also anpassen. Aber wenn Du keinen guten Grund hast, dann solltest Du es schlicht sein lassen:

• Clean Code Gedanke - man sollte nur Dinge machen, die Andere auch erwarten. Niemand will erst in deine POM schauen um zu sehen, was für komische Ideen Dir dabei gekommen sind.
• Konventionen über Konfigurationen - Sich daran zu halten ermöglicht es u.a., dass Du viele Konfigurationen direkt kopieren kannst. Du brauchst etwas in Deinem Maven Projekt? Eine Suche gibt dir auf SO oder so einen Ausschnitt, den Du in der Regel relativ einfach kopieren kannst und fertig. Weich von den Konventionen ab und die Chancen steigen, dass Du ohne Anpassungen Dinge nicht übernehmen kannst!

Unit-Tests sturr in ein eigenes Maven-(Unter)-Projekt packt

Wozu? Du schreibst die Unit Tests direkt mit den zu testenden Units. Wozu das in zwei Projekte packen? Dann müsstest Du entweder bei den Verzeichnissen rumpfuschen (Damit ein Projekt direkt auf das andere Projekt zugreift oder so) oder Du musst bei allen Läufen sicher stellen, dass Du erfolgreich übersetzt und es ins lokale Repository deployed hast. Du verkomplizierst also die Entwicklung schlicht unnötig.

Wenn Du keine Unit Tests sondern Integrationstests oder so machst, dann ist es etwas anderes, dann testest Du ja auch eine fertig übersetzte und (lokal) installierte Software. Das nur als wichtigen Punkt. Schau Dir an, was Du genau machen willst und dann nimm einen Aufbau, der sinnvoll ist. Und das ist halt auch wichtig, wenn es um die Frage geht, in was für Maven Module man etwas unterteilt. Hier von Anfang an eine massive Unterteilung zu haben ohne irgend eine Notwendigkeit dazu, ist einfach unnötig (und daher Quatsch in meinen Augen). Das nur, weil ich da einen Thread im Kopf habe, der wohl auch von Dir war...

 

[Zrebna]

Das ist eine Konvention, die in Maven einmal festgelegt wurde. Dies kannst Du z.B. in der Super POM erkennen:
Super POM (apache.org)
Dort siehst du dann in build die Festlegung testSourceDirectory:
<testSourceDirectory>${project.basedir}/src/test/java</testSourceDirectory>

Und ja - das könntest Du einfach umändern. Setz einfach testSourceDirectory in Deiner POM und schon liegt es woanders.

Wenn Du einen guten Grund hast, dann kannst Du es also anpassen. Aber wenn Du keinen guten Grund hast, dann solltest Du es schlicht sein lassen:

• Clean Code Gedanke - man sollte nur Dinge machen, die Andere auch erwarten. Niemand will erst in deine POM schauen um zu sehen, was für komische Ideen Dir dabei gekommen sind.
• Konventionen über Konfigurationen - Sich daran zu halten ermöglicht es u.a., dass Du viele Konfigurationen direkt kopieren kannst. Du brauchst etwas in Deinem Maven Projekt? Eine Suche gibt dir auf SO oder so einen Ausschnitt, den Du in der Regel relativ einfach kopieren kannst und fertig. Weich von den Konventionen ab und die Chancen steigen, dass Du ohne Anpassungen Dinge nicht übernehmen kannst!

Wozu? Du schreibst die Unit Tests direkt mit den zu testenden Units. Wozu das in zwei Projekte packen? Dann müsstest Du entweder bei den Verzeichnissen rumpfuschen (Damit ein Projekt direkt auf das andere Projekt zugreift oder so) oder Du musst bei allen Läufen sicher stellen, dass Du erfolgreich übersetzt und es ins lokale Repository deployed hast. Du verkomplizierst also die Entwicklung schlicht unnötig.

Wenn Du keine Unit Tests sondern Integrationstests oder so machst, dann ist es etwas anderes, dann testest Du ja auch eine fertig übersetzte und (lokal) installierte Software. Das nur als wichtigen Punkt. Schau Dir an, was Du genau machen willst und dann nimm einen Aufbau, der sinnvoll ist. Und das ist halt auch wichtig, wenn es um die Frage geht, in was für Maven Module man etwas unterteilt. Hier von Anfang an eine massive Unterteilung zu haben ohne irgend eine Notwendigkeit dazu, ist einfach unnötig (und daher Quatsch in meinen Augen). Das nur, weil ich da einen Thread im Kopf habe, der wohl auch von Dir war...

Zur Klarstellung:
Ich will nicht Unit-Tests in ein eigenes maven-Unterprojekt auslagern und habe mich aber nur gefragt, ob so ein Vorgehen Konsequenzen hätte - und zwar Konsequenzen, die über eine Verletzung von best practices und Konventionen hinausgehen.

Das könnte so ein Punkt sein, der "wirkliche" Probleme machen könnte:
"Dann müsstest Du entweder bei den Verzeichnissen rumpfuschen (Damit ein Projekt direkt auf das andere Projekt zugreift oder so)..."

Bei Unit-Tests verwendet man ja keine externen Abhängigkeiten und will nach Möglichkeit auch wenig mocken müssen. Daher ist es alleine schon aus Zugriffsgründen gut, wenn die zu testende Klasse und die testende Klasse im selben Projekt liegen.

Nochmal, ich suche eben Contra-Argumente gegen das Auslagern von Unit-Tests in eigene Maven-Projekte, und somit gegen das Brechen der gängigen Konvention.

 

[LimDul]

Unit-Tests sind Bestandteil der Unit die sie testen. Warum anders machen? Wenn man etwas anders macht, als die Konventionen, braucht man erst mal keine Argumente warum es schlechter ist - es ist gegen die Konventionen, sondern Argumente warum es besser sein soll. Diverse Tools werden dann nicht mehr out of the box funktionieren, wie z.B. die Messung der Code-Abdeckung, weil die in Sonar beispielsweise nur innerhalb des Moduls gemessen wird. Und mit Sicherheit zig andere Tools auch.

Wenn man Konventionen verletzt, bricht man implizit alle Tools die sich auf diese Konventionen verlassen. Das ist schon ein extrem starkes Argument, wo man erst mal ein Pro Argument braucht um überhaupt weiter zu diskutieren, warum es sinnvoll sein könnte.

 

[KonradN]

Bei Unit-Tests verwendet man ja keine externen Abhängigkeiten

Doch natürlich hast Du Abhängigkeiten. Du hast mindestens das Unit-Test Framework wie JUnit aber oft auch weitere Libraries, die Du für effektive Tests benötigst wie z.B. Mockito.

und will nach Möglichkeit auch wenig mocken müssen.

Aber genau das bleibt bei Unit Tests - so dies wirklich Unit Tests sind - nicht aus. Denn dann willst Du ja wirklich nur die Unit selbst testen. Damit musst Du alles, was nicht die Unit selbst ist, mocken.

ich suche eben Contra-Argumente gegen das Auslagern von Unit-Tests in eigene Maven-Projekte

Dazu hatte ich ja auch etwas geschrieben:

Dann müsstest Du entweder bei den Verzeichnissen rumpfuschen (Damit ein Projekt direkt auf das andere Projekt zugreift oder so) oder Du musst bei allen Läufen sicher stellen, dass Du erfolgreich übersetzt und es ins lokale Repository deployed hast. Du verkomplizierst also die Entwicklung schlicht unnötig.

Daher kann ich Dir nur empfehlen, es einfach mal zu machen / es zu probieren. Dann wirst Du ja sehen, wie Gut es geht und was für Probleme es mit sich bringt.

Wenn man z.B. nach TDD vorgeht, dann rufst Du ständig Unit Tests auf:

• Ist der neue Test wirklich rot?
• Ist durch die (minimale) Anpassung alles grün?
• Ist nach dem Refactoring alles grün?

Und da ist halt wichtig, dass die Unit Tests immer mit der letzten Version des Sources arbeiten. Was ist notwendig, damit das Test Modul die Änderungen vom Code-Modul hat?

Es ist wichtig, dass Unit Tests schnell laufen und dass du diese einfach aufrufen kannst. Es geht sogar so weit, dass es AddOns für Entwicklungsumgebungen gibt, die im Hintergrund automatisch die Unit-Tests ausführen. (IntelliJ hat in Ultimate das Auto-Test, Eclipse hat das Plugin Infinitest)

Also hier ist die Praxis einfach wichtig. Und wenn Du es ausprobierst und damit einfach mal etwas arbeitest, dann wirst Du merken, ob es noch praktikabel ist oder eben nicht...

 

[Zrebna]

Doch natürlich hast Du Abhängigkeiten. Du hast mindestens das Unit-Test Framework wie JUnit aber oft auch weitere Libraries, die Du für effektive Tests benötigst wie z.B. Mockito.

Schlecht ausgerückt von mir - meinte:
Units sollen isoliert von externen Abhängigkeiten gestet werden- daher muss man diese mocken, wenn man welche braucht.

Aber genau das bleibt bei Unit Tests - so dies wirklich Unit Tests sind - nicht aus. Denn dann willst Du ja wirklich nur die Unit selbst testen. Damit musst Du alles, was nicht die Unit selbst ist, mocken.


Dazu hatte ich ja auch etwas geschrieben:

Daher kann ich Dir nur empfehlen, es einfach mal zu machen / es zu probieren. Dann wirst Du ja sehen, wie Gut es geht und was für Probleme es mit sich bringt.

Wenn man z.B. nach TDD vorgeht, dann rufst Du ständig Unit Tests auf:

• Ist der neue Test wirklich rot?
• Ist durch die (minimale) Anpassung alles grün?
• Ist nach dem Refactoring alles grün?

Und da ist halt wichtig, dass die Unit Tests immer mit der letzten Version des Sources arbeiten. Was ist notwendig, damit das Test Modul die Änderungen vom Code-Modul hat?

Es ist wichtig, dass Unit Tests schnell laufen und dass du diese einfach aufrufen kannst. Es geht sogar so weit, dass es AddOns für Entwicklungsumgebungen gibt, die im Hintergrund automatisch die Unit-Tests ausführen. (IntelliJ hat in Ultimate das Auto-Test, Eclipse hat das Plugin Infinitest)

Also hier ist die Praxis einfach wichtig. Und wenn Du es ausprobierst und damit einfach mal etwas arbeitest, dann wirst Du merken, ob es noch praktikabel ist oder eben nicht...

TDD will ich selber in meinem kleinen Hobbyprojekt ausprobieren, einfach als Lernmittel.

 

[mrBrown]

Ich will nicht Unit-Tests in ein eigenes maven-Unterprojekt auslagern und habe mich aber nur gefragt, ob so ein Vorgehen Konsequenzen hätte - und zwar Konsequenzen, die über eine Verletzung von best practices und Konventionen hinausgehen.

Split-Packages sind ein mögliches Problem, wenn man die Tests im selben Package liegen hat, um default und protected Scope nutzen zu können.

 

[KonradN]

TDD will ich selber in meinem kleinen Hobbyprojekt ausprobieren, einfach als Lernmittel.

Auch wenn das Off Topic ist: Das ist mit das Beste, was man machen kann. Bezüglich TDD in der Praxis mag man durchaus geteilter Meinung sein, so empfinde ich es als ungewohnt, da ich halt gewohnt bin, dass Dinge vorhanden sind und ich dann die Autovervollständigung nutze. Bei dem TDD Ansatz ist es aber so, dass man regelmäßig Dinge nutzt, die noch nicht da sind um da dann mit Hilfe der IDE diese zu erstellen. Das ist nicht schlechter nur eben für mich ungewohnt. Liegt aber garantiert auch mit daran, dass ich bisher kein Projekt hatte, in dem ich das einfach dauerhaft umsetzen konnte - denn ich bin sicher, dass da sehr schnell eine Umgewöhnung statt finden dürfte.

Aber das durchzuführen hilft auf jeden Fall ganz stark bezüglich: Wie sieht gut testbarer Code aus. Ohne diese Übung ist es meiner Erfahrung nach oft so, dass man Code hat, der einfach nicht testbar ist. Und das macht es einem extrem schwer und führt aus meiner Sicht dann oft zu negativen Erfahrungen und damit verbunden der Ablehnung von Unit Tests (da hatten wir hier im Forum schon massive Diskussionen drum, wo einzelne Senior Software Engineers Unit Tests für Zeitverschwendung hielten).

Daher auch hier die Off Topic Antwort, um Dich in dem Punkt zu bestärken! Das ist auf jeden Fall super und wird Dir aus meiner Sicht durchaus viel bringen.