TestSuites in Eclipse mit jUnit 4 (Nachtrag)

Das Problem: Wenn man in einem Projekt eine Reihe von Testcases gemacht hat, dann sind diese meist (natürlich) auf verschiedene Packages verteilt. Außerdem gibt es ja reine Komponententests als auch Usecasetests (soweit möglich), oder das Testen zweier oder mehrere Komponenten im Verbund. Schlussendlich also eine große Anzahl von „TestCase“-Klassen, die jeweils mehrere Tests haben. Ideal wäre also, wenn man diese ganzen Testcases zusammenpacken könnte.. und dann auch ausführen könnte.

jUnit bietet (in Eclipse) dafür die Option TestSuite an. Eine TestSuite ist ja auch genau das, was wir brauchen. Leider zeigt der Wizard keine unserer TestCases an.. warum? Nach einigem Recherchieren (viele Suchergebnisse zeigen indirekt noch auf jUNit 3.8) ist die Frage eigentlich simpel gelöst.. wenn man denn weiß, wie 😉

Als erstes müssen alle TestCase-Klassen (d.h. hier die Klasse MyTests, die @Test-Methoden enthält) eine neue Methode erhalten:

public static junit.framework.Test suite() {
return new JUnit4TestAdapter(MyTests.class);
}

Damit erkennt der Wizard für eine TestSuite nun auch jene Klassen.

Falls man es lieber manuell machen möchte (Beispiel): suite.addTest(MyTests.suite());f

Es ist übrigens kein Problem, TestSuites zu verschachteln – dafür einfach das Prozedere „wiederholen“ bzw. suite.addTest(MyOtherSuite.suite()) schreiben. Tipp: Es gibt die äußerst hilfreiche Methode suite.setName(string) – damit man sich in der jUnit-Baumansicht nicht verwirrt.

Nachtrag:

Wesentlich eleganter ist natürlich der Annotation-Weg. Die „SuperTestSuite“ braucht „nur“ so auszusehen:

@RunWith(Suite.class)
@SuiteClasses( { MySuite1.class, MySuite2.class, MySuite3.class })

public class AllTests {
}

Java-Applikation als Mac-Anwendung deployen (Ant)

Wie bereits berichtet, ist es von Vorteil, der Buildprozess mit einem Ant-Script zu automatisieren. Um eine Mac-Application zu erstellen, muss man nur wissen, wie eine solche Application aufgebaut ist.. der Rest ist ein Klacks.

Eine Mac-Application ist ein Verzeichnis mit der Erweiterung .app. Die Struktur einer Application (wir nennen sie im Folgenden Application) sieht wie folgt aus:

  • Application.app
    • Contents
      • Info.plist — Properties-Datei für die Anwendung und Java
      • MacOS — Verzeichnis
        • JavaApplicationStub — Bootloader für Javaprogramme
      • PkgInfo — Datei mit Entwicklerinfo
      • Resources — Verzeichnis mit dem eigentlichen Javaprogramm
        • Java
          • Die Jars und so.

Den Bootloader befindet sich auf einem Mac in dem Ordner /System/Library/Frameworks/JavaVM.framework/Resources/MacOS/JavaApplicationStub.

Prinzipiell kann man sich diese Struktur komplett selber erstellen; es ist aber zu Empfehlen, den initialen Prozess durch das Programm /Developer/Applications/Utilities/Jar Bundler zu machen. Mit Hilfe dieses Programmes lässt sich für eine bereits fertige JAR die Application erstellen.

Anschließend kopiert man das erstellte Resultat – quasi als Vorlage – in ein Verzeichnis für die Builds. In meinem Fall in dem build_data Verzeichnis. Ein Ant-Task erstellt darauf hin im Verzeichnis deploy eine Application. Die Vorlage ist idealerweise auch im SVN und auch später noch veränderbar – beispielsweise durch das Ändern des Applicationicon, -titel oder anderen Einstellungen.

Wichtig 1: Bei Verwendung von FatJar muss man als Package für die Main den Bootloader von FatJar (com.simontuffs.onejar.Boot) verwenden. Dies erkennt das Programm Jar Bundler aber auch automatisch.

Wichtig 2: Beim Kopieren der Dateien kann es passieren, dass die Rechte an der JavaApplicationStub verloren gehen. Diese muss als ausführbar markiert sein. Ein entsprechender Ant-Befehl stellt das sicher.

<target name="makeMac" depends="makeNormal">
<copy todir="deploy/Application.app">
<fileset dir="build_data/Application.app"/>
</copy>
<!-- chmod the application stub file executable -->
<chmod file="deploy/Application.app/Contents/MacOS/JavaApplicationStub" perm="755"/>
<copy file="deploy/Application.jar" tofile="deploy/Application.app/Contents/Resources/Java/Application.jar" />
</target>

Automatischer Deploy von Java-Applikationen oder: Ant Builds mit externen Jars und SVN-Informationen

Der Eclipse-verwöhnte Programmierer braucht sich eigentlich nicht mit Begriffen wie Deploy oder Build herumschlagen — zumindestens nicht so lange man in der Entwicklung ist. Ein Knopfdruck auf „Run“ und das Programm läuft. Sowohl alle lokalen Resourcen als auch alle externen Jars werden gefunden, eingebunden und können einwandfrei genutzt werden.

Möchte man die Applikation nun fertigstellen und anderen zur Verfügung stellen – oder früher im Rahmen von Enduser-Tests – so kommt es bei großen Projekten unweigerlich zu Problemen.

Im Folgenden beschäftige ich mit den Problemen:

  1. Wie exportiere ich ein Projekt mit vielen externen Jars einfach und sicher in ein lauffähiges Jar?
  2. Wie stelle ich sicher, das sowohl in der Entwicklungsumgebung als auch in der Jar alle Bilder o.ä. Ressourcen wiedergefunden werden?
  3. Wie nutze ich einen eigenen Buildprozess und
  4. Wie kann ich im Buildprozess Zusatzinformationen wie die aktuelle SVN-Revision oder das Build-Datum verwerten?

„Automatischer Deploy von Java-Applikationen oder: Ant Builds mit externen Jars und SVN-Informationen“ weiterlesen

Neue Reihe „Diplomarbeit.. ftw!“

da-build-160409-01

So, wenn man spontane Ideen hat, sollen sie ja ganz gut sein. Fein, der Titel ist ‚mal ganz spontan entstanden, weil mir nichts besseres eingefallen ist. 🙂

Seit diesem Monat stecke ich in meiner Diplomarbeit: Die Entwicklung eines Tools, mit dem man die Abhängigkeiten von Views und

Triggern in einer Datenbank analysiert, parst und anschließend visuell (sprich in Graphen) anzeigt. Das ganze muss auch persistent gespeichert werden, da der Prozess je nach Größe der Datenbank etwas dauern kann.

Für rund vier Wochen intensiven Arbeitens (zu zweit) hat unsere in Java geschriebene Applikation bereits große Fortschritte gemacht. Sowohl das Auslesen als auch das Parsen von mehrschichtigen Views klappt, als auch das Lesen und Speichern in einen nichtflüchtigen Speicher (HSQLDB). Außerdem haben wir bereits einen Prototypen zur Visualisierung.

Anbei einen Screenshot der aktuellen Build (Mac OS X). Die Anwendung sieht unter einem Mac leider immer noch sehr „Java“ aus. Die Menubar habe ich zwar bereits nach oben „verdonnert“, aber es reicht nicht aus. Abhilfe schafft hier das das Projekt MacWidgets, das eine Reihe von Swing-Komponenten selbst zeichnet. Mit dem optionalen Code da-build-160409-02sieht die Anwendung bereits etwas schniker aus.

Weitere technische Details zur Anwendung:

  • HSQLDB als lokale Datenbank zum Ablegen der Schemata und Datenbankverbindungen
  • Hibernate als OR-Wrapper um Hibernate; die Anwendung produziert 0 Sql-Statements
  • JUNG2 als Graphenframework zum Zeichnen der Elemente (späterer Blogeintrag wird dies zeigen)
  • JavaBuilders/SwingX als idealer Layouter für Formulare, wie unseren Connectiondialog (späterer Blogeintrag wird dies zeigen)