Unit-Testing in Multi-Projekt-Settings

November 1, 2006 at 7:40 pm 3 comments


Die Eclipse-IDE bietet sich an, um ein Gesamtprojekt in mehrere Subprojekte/Komponenten zu unterteilen. Die Abhängigkeitsverwaltung in Eclipse sichert dabei, dass man keine ungewollten Abhängigkeiten in sein System einbaut.
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.

Entry filed under: Uncategorized. Tags: .

DROP COLUMN Fußballweisheit von Oli Kahn

3 Comments Add your own

  • 1. Sebastian  |  November 2, 2006 at 10:59 am

    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

  • 2. Sebastian  |  November 3, 2006 at 4:32 pm

    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

  • 3. Stefan  |  November 8, 2006 at 10:36 pm

    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

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Trackback this post  |  Subscribe to the comments via RSS Feed



%d bloggers like this: