Ich suche nach Möglichkeiten, eine Reihe von Eclipse-Plugins zu testen, ohne für jedes getestete Plugin ein einziges Bundle verwenden zu müssen. Derzeit habe ich einen PDE-Build für ein Eclipse-Produkt (etwa 70 Plugins, Features und ein Produkt) laufen. Alle Komponententests für alle Plugins sind in einem einzigen plain-java Projekt enthalten, mit einem Eclipse-Projekt Verweis auf alle Plugins, um die Klassen instanziieren und die Tests ausführen zu können. Dieses Setup funktioniert nicht mehr, da ich den PDE-Build in maven tycho umgewandelt habe, da das Plain-Java-Projekt alle Zielplattform-Projekte vermisst. Ich führe keine echten OSGI-Plugin-Tests durch, aber einige Tests erfordern, dass die Kern-Eclipse-Klassen wie IProgressMonitor im Klassenpfad enthalten sind, da ich diese Eclipse-Laufzeitschnittstellen auch in eigenen Methodensignaturen verwende.Eclipse Tycho: Testen von Plug-Ins ohne Verwendung einzelner Test-Bundles
Nach dem neuen Maven tycho Build Einrichten erfolgreich habe ich versucht, ein paar Möglichkeiten, um die Tests zu bekommen läuft wieder:
1) Die Umwandlung des plain-Java-Testprojekt in ein Plugin Testprojekt
Nachteile:
- um in der Lage sein, interne Pakete zu testen Klassen, ich habe jedes einzelnes Paket mit x-friend exportieren: Notation und habe dieses Verfahren für jedes neues getesteten Paket wiederholen
2) einen zweiten Quellordner hinzufügen im jedes Plugin und verschiebe die Tests in das entsprechende Plugin Nachteile:
- Tycho scheint build.properties zu verwenden, um die erforderlichen Quellordner für den Kompilierungsschritt einzuschließen. Da sowohl src/main/java als auch src/test/java als Quellordner registriert werden müssen, werden die realen Klassen und die Testklassen im Ausgabeordner target/classes verwechselt und schließlich in der JAR-Datei des Plugins enthalten. Ich habe keine Möglichkeit gefunden, Tycho zu konfigurieren, um src/main/java als sourceDirectory und src/test/java als testSourceDirectory zu verwenden.
- Tycho führt die Komponententests nur aus, wenn der Pakettyp "eclipse-test-plugin" ist
- Sonar scheint Tests auf diese Weise nicht zu erkennen (ich habe nicht viel Zeit damit verbracht, dieses Problem zu lösen, vielleicht gibt es eine einfache Lösung für diesen Punkt)
3) Fügen Sie die notwendigen eclipse-Zielplattform Plugins als plain-maven-Abhängigkeit in die Ebene-java Testprojekt
Nachteile:
- die Zielplattform Informationen dupliziert einmal in der Zielplattform für den Tycho-Build und einmal in der Maven-Abhängigkeitsliste des Testprojekts (ausgeführt mit plain maven-todefire)
- die Zielplattform Bündel werden zweimal in der Artifactory, einmal als Zielplattform p2 Archiv bereitgestellt, und einmal als maven Abhängigkeiten (Plugin + POM)
4) ein Testfragments für jedes Plugin Hinzufügen (dies scheint zu sein, die normalerweise gewählte Möglichkeit) Nachteile:
- Benötigt einen riesigen Aufwand (> 70 Plugins,> 4500 Unit Tests), also müsste ich etwa 70 neue Fragmente hinzufügen und alle Tests aufteilen.
Im Moment scheint die Möglichkeit 3) das vernünftigste für mich zu sein ... irgendwelche Vorschläge? andere Ideen?
Nur eine weitere Idee: Sie könnten auch einfach die 70 Bundles zusammenführen ... Aber wenn es einen guten Grund gibt, den produktiven Code in Bündel zu trennen, ist es wahrscheinlich auch sinnvoll, die Tests zu trennen. Ich sehe nicht, warum Tests getrennt behandelt werden sollten (außer Migrationsbemühungen). – oberlies
Es wäre auf jeden Fall sinnvoll, das Testprojekt in einzelne Pakete aufzuteilen, aber das würde wochenlange Arbeit erfordern, die wir nicht haben (und nicht bezahlt werden). Wir haben uns für den Ansatz 3 entschieden, aber vor anderen Problemen, habe ich die obige Frage aktualisiert. Vorschläge? – Paolo
Paolo, es ist großartig, dass Sie Ihren Beitrag mit Ihren Ergebnissen aktualisieren, aber Sie sollten Ihre Lösung in eine Antwort bringen. Das Beantworten einer eigenen Frage ist explizit auf stackoverflow erlaubt. – oberlies