Unverständlicherweise kann man in Eclipse aber nicht Unit-Tests über mehrere Projekte auf einmal ausführen. Wenn man sehr viele Projekte in Eclipse hat, wird das Ausführen der Unit-Tests zur echten Qual.
Aber es gibt eine ganz einfache Lösung über eine generische Test-Suite, die einfach alle Tests im Classpath ausführt. Den Code (< 100 Zeilen) dazu findet man bei Björn Martensson.
Post bewerten
Atom.xml
3 Kommentare:
Hallo Stefan,
wir haben uns in einem Eclipse-Projekt lieber dafür entschieden alle Test-Suites programmatisch zu bauen. Auf den ersten Blick wirkt Deine bzw Björn Martenssons Lösung pragmatischer, aber im Projektverlauf ist sie schwerer zu warten!
Für jedes fachliche Plugin gibt es parallel ein Test-Plugin, um Tests vom fachlichen Code zu trennen. Dort sammelt pro Package je eine Test-Suite alle Testklassen ein. Für das Test-Plugin gibt es eine Test-Suite, die alle Package-Tests-Suites einsammelt. Zu alledem gibt es noch ein extra Plugin, das alle Plugin-Tests-Suites vereinigt ("all-tests").
Damit ist man viel schneller als mit der Lösung allles per Reflection zu sammeln. Zudem kann man dann auch nur für ein Package oder nur für ein Plugin schnell alle Tests laufen lassen. Die hierarchische Ansicht bei JUnit entspricht dann auch der Strukturierung im Projekt bzw. den Plugins.
Natürlich ist es ein ganz bisschen aufwendiger alle Tests in diesen Suites zu verwalten, aber der Aufwand ist geringer als wir vorher befürchtet haben. Auf Ebene der Packages gibt es im JDT von Eclipse in jeder Installation den Menüpunkt "Recreate Testsuite". Beim Schreiben eines neuen Tests muss man das einfach mal durchlaufen lassen. Auch wenn man nur alte Tests anfässt ist das damit sehr wenig Aufwand zu schauen, ob die Tests noch alle in der Suite sind. Und falls man doch eine ganze Package-Testsuite in der Plugin-Testsuite vergisst, fällt das schon bei Abdeckung auf.
Insgesamt hatten wir damit weniger Aufwand nach der Umstellung auf Test-Suites im Vergleich zu der Lösung die Du hier postest - und die wir so ähnlich vorher benutzt haben. Außerdem konnten wir dann einfacher Komponenten- und integrations-Tests voneiander trennen.
Gruß - Sebastian
Hallo Stefan,
wir haben uns in einem Eclipse-Projekt lieber dafür entschieden alle Test-Suites programmatisch zu bauen. Auf den ersten Blick wirkt Deine bzw Björn Martenssons Lösung pragmatischer, aber im Projektverlauf ist sie schwerer zu warten!
Für jedes fachliche Plugin gibt es dort parallel ein Test-Plugin, um Tests vom fachlichen Code zu trennen. Dort sammelt pro Package je eine Test-Suite alle Testklassen ein. Für das Test-Plugin gibt es eine Test-Suite, die alle Package-Tests-Suites einsammelt. Zu alledem gibt es noch ein extra Plugin, das alle Plugin-Tests-Suites vereinigt ("all-tests").
Damit ist man viel schneller als mit der Lösung allles per Reflection zu sammeln. Zudem kann man dann auch nur für ein Package oder nur für ein Plugin schnell alle Tests laufen lassen. Die hierarchische Ansicht bei JUnit entspricht dann auch der Strukturierung im Projekt bzw. den Plugins.
Natürlich ist es ein ganz bisschen aufwendiger alle Tests in diesen Suites zu verwalten, aber der Aufwand ist geringer als wir vorher befürchtet haben. Auf Ebene der Packages gibt es im JDT von Eclipse in jeder Installation den Menüpunkt "Recreate Testsuite". Beim Schreiben eines neuen Tests muss man das einfach mal durchlaufen lassen. Auch wenn man nur alte Tests anfässt ist das damit sehr wenig Aufwand zu schauen, ob die Tests noch alle in der Suite sind. Und falls man doch eine ganze Package-Testsuite in der Plugin-Testsuite vergisst, fällt das schon bei Abdeckung auf.
Insgesamt hatten wir damit weniger Aufwand nach der Umstellung auf Test-Suites im Vergleich zu der Lösung die Du hier postest - und die wir so ähnlich vorher benutzt haben. Außerdem konnten wir dann einfacher Komponenten- und integrations-Tests voneiander trennen.
Gruß - Sebastian
Sebastian hatte Probleme mit der Kommentarfunktion in diesem Blog. Daher poste ich den Kommentar an seiner Stelle:
Hallo Stefan,
wir haben uns in einem Eclipse-Projekt lieber dafür entschieden alle Test-Suites programmatisch zu bauen. Auf den ersten Blick wirkt Deine bzw Björn Martenssons Lösung pragmatischer, aber im Projektverlauf ist sie schwerer zu warten!
Für jedes fachliche Plugin gibt es dort parallel ein Test-Plugin, um Tests vom fachlichen Code zu trennen. Dort sammelt pro Package je eine Test-Suite alle Testklassen ein. Für das Test-Plugin gibt es eine Test-Suite, die alle Package-Tests-Suites einsammelt. Zu alledem gibt es noch ein extra Plugin, das alle Plugin-Tests-Suites vereinigt ("all-tests").
Damit ist man viel schneller als mit der Lösung allles per Reflection zu sammeln. Zudem kann man dann auch nur für ein Package oder nur für ein Plugin schnell alle Tests laufen lassen. Die hierarchische Ansicht bei JUnit entspricht dann auch der Strukturierung im Projekt bzw. den Plugins.
Natürlich ist es ein ganz bisschen aufwendiger alle Tests in diesen Suites zu verwalten, aber der Aufwand ist geringer als wir vorher befürchtet haben. Auf Ebene der Packages gibt es im JDT von Eclipse in jeder Installation den Menüpunkt "Recreate Testsuite". Beim Schreiben eines neuen Tests muss man das einfach mal durchlaufen lassen. Auch wenn man nur alte Tests anfässt ist das damit sehr wenig Aufwand zu schauen, ob die Tests noch alle in der Suite sind. Und falls man doch eine ganze Package-Testsuite in der Plugin-Testsuite vergisst, fällt das schon bei Abdeckung auf.
Insgesamt hatten wir damit weniger Aufwand nach der Umstellung auf Test-Suites im Vergleich zu der Lösung die Du hier postest - und die wir so ähnlich vorher benutzt haben. Außerdem konnten wir dann einfacher Komponenten- und integrations-Tests voneiander trennen.
Gruß - Sebastian
Kommentar veröffentlichen