Ich bin aktuell an einem Punkt in einem meiner Maven Projekte gelangt an dem ich eine Entscheidung treffen muss. Undzwar habe ich folgende Ausgangslage:
Projekt A ist eine reine (naja 90%) API die hauptsächlich Interfaces und Utility Sachen bereitstellt.
Projekt B&C sind verschiedene implementierungen von Projekt A, haben dieses also als Abhängigkeit.
Da ich mal ordentlich sein will und Tests machen will (die vermutlich auch wieder mehr als Unit Tests sind) hatte ich überlegt, in Projekt A ein Dummy Test für eine zu implementierende Komponente zu schreiben, den ich dann in Projekt B&C anwenden kann und dabei nur die entsprechende Implementierung (z.b. mittels @SetUp)
einsetze. Nur leider stellt sich das als nicht so leicht dar wie ich gehofft habe.
Das Problem ist vorallem, ich komm nicht an die Klassen ran aus dem Test package. Wenn ich den Scope von Projekt A auf “test” mache schlägt natürlich der Build fehl. Wenn ich, wie schon an verschiedenen Stellen gelesen, den Scope auf “runtime” mache, funktioniert es ebenfalls nicht (Build sowie Zugriff auf die Klassen).
Mir kamen jetzt nur noch 2 Ideen:
Test einmal schreiben und dann Copy&Paste (unschön und möchte ich vermeiden)
Test in Projekt A schreiben und mit @RunWith(Parameterized.class) und für jede Implementierung (jedenfalls die, die von mir sind und ich ja kenne) den Test ausführen lassen.
Was mir an 2. nicht gefällt ist einmal, dass ich dann (zwar nur für scope = test) eine Abhängigkeit zu Projekt B&C habe und die Ergebnisse der Implementierung für Projekt A gewertet werden vom CI-Server. (das mit dem CI-Server ließe sich vllt noch aufwändig umbiegen aber darauf würde ich auch gerne verzichten).
Kennt von euch eventuell jemand noch Möglichkeit 3-n bzw. wie man in einer solchen Situation am besten vorgeht? Vllt hab ich mich auch total verrannt und sollte das ganze ganz anders angehen.
Teste in Projekt A alles, was dort konkret implementiert und damit testbar ist. Es macht bspw. keinen Sinn, abstrakte Methoden zu testen. Teste in Projekt B alles, was dort implementiert ist. Die Dependencies aus A sind sind in A getestet und brauchen nicht nochmals getestet zu werden.
Also zunächst ist mir erstmal unklar, wie ein Test in einem Basis-Projekt Implementierungen in einem darauf aufbauenden Projekt testen soll. Woher soll der Test wissen, wie das gewünschte Verhalten im konkreteren Projekt ist? Das Einzige, was der testen könnte wäre, dass die API erfüllt ist, also die Schnittstelle stimmt, dafür sorgt aber schon das Interface…
Abseits von der Sinnfrage gibt es aber technische Lösungen.
Du musst deine Tests (die hoffentlich in src/test/java liegen) als selbstständiges Artefakt bereit stellen:[XML]
org.apache.maven.plugins
maven-jar-plugin
2.4
jar
test-jar
[/XML]Das kannst Du dann im Scope “test” in den Projekten nutzen, die die Tests einsetzen und erweitern sollen.
Diesen Weg bin ich auch schon gegangen bzw. versucht (Mein Fehler, dass ich das vergessen hatte). Nur war mir dann nicht klar wie ich genau ich das Test Jar dann einbinde aber ich werde es heute Abend nochmal versuchen.
Inwiefern muss ich das dann einbinden? So wie die normale Abhängikeit auch nur mit Scope “test”? Also hat man dann quasi 2 Abhängikeiten zum selben Projekt mit unterschiedlichem Scope und Maven sucht sich dann das entsprechende Jar File.
[quote=Clayn]Inwiefern muss ich das dann einbinden? So wie die normale Abhängikeit auch nur mit Scope “test”?[/quote]Ja
[quote=Clayn;137491]Also hat man dann quasi 2 Abhängikeiten zum selben Projekt mit unterschiedlichem Scope und Maven sucht sich dann das entsprechende Jar File.[/quote]ja
Lässt man Unittests nicht in der Regel im Modul, in dem die Unit sich befindet und macht ein Testmodul nur für darüber hinausgehende Tests wie Integrationstests?
richtige Unit Test schon, also Whitebox tests welche direkt die Implementierung isoliert (durch Mocks zB.) testen.
Clayn scheint aber eher gegen das Interface testen zu wollen, derselbe test fuer verschiedene Implementierungen.
Also keine Unit Tests, sondern eher funktionale bzw. akzeptanz Tests, also schon integration tests
surefire version sollte die aktuelle sein, also 2.19.1, mindestens aber 2.15
Es wuerde sich auch anbieten, ein eigenes Modul fuer die Tests zu machen.[/QUOTE]
Werde ich mir dann auch mal genauer anschauen. Mit surefire mach ich glaube ich schon was (Goal: “site”) erzeugt jedenfalls einen Ordner surefire wenn ich mich richtig erinnere
Edit:
Was ich nicht so alles will^^ Aber ja, ich hab da nie so eine wirkliche Grenze was Tests angeht… wenn ich denn mal welche mache. Aber vor kurzem war ich sehr stolz auf mich, dass ich sogar mal Mocks benutzt habe in Tests… ob auch wirklich sinnvoll sei mal dahin gestellt
@maki : danke für die Klarstellung. Ich war über die Pauschalität der Aussage etwas irritiert. Dass es sich bei @Clayn s Anliegen wohl um “etwas mehr als Unittests” handelt, hatte er ja auch angedeutet.
Mal nebenbei erwähnt werdet: Ihr werdet erfahren um was es ging, da ich, wenn ich das mit den Tests (den Ablauf weniger die Abdeckung) habe, ich die ganze Schose hier veröffentlichen wollte
A friendly warning - this is no longer valid for Maven 3 (used to be valid for Maven 2). Maven 3 will attempt to obtain the nearest dependency, effectively ensuring that only one of the compile or test scoped dependency is used for both the compile and test phases.
Das deckt sich auch mit meiner Beobachtung, dass nur die Abhängigkeit, die zuletzt deklariert wurde, genommen wird.
Verstehe das Problem nicht, in dem Link geht es darum, verschiedene Versionen einer Dependency fuer verschiedene Scopes zu nutzen, das wurde repariert in Maven 3, weil es offensichtlich kaputt war in Maven 2.
