Beispiele für entsprechende Anwendungsfälle sind leicht zu finden. So kann dies beim Beenden einer Anwendung verwendet werden, um diese nach einem Neustart wiederherstellen, oder im Fehlerfall einen auftretenden Fehler rekonstruieren zu können.

Diese zwei Beispiele zeigen, wie wichtig die Serialisierung von Objekten sein kann.

Für dessen Realisierung stehen dem Programmierer neben der Java-Schnittstelle Serializable, noch entsprechende externe Bibliotheken zur Verfügung. Ein sehr interessanter Vertreter der Kategorie “Bibliotheken”, der zugleich frei Verfügbar ist, stellt Prevayler dar. Der neben seiner beeindruckenden Performance, noch Fehlertoleranz und Load-Balancing unterstützt. Dabei unterhält er nicht, wie andere Persistenz-Layer (z.B. Hibernate), die Daten der Objekte in einer relationalen Datenbanken, sondern im Arbeitsspeicher und sichert die Objekte in bestimmten Intervallen auf der Festplatte.

Wer sich für dieses Thema interessiert und auf Persistenz angewiesen ist, wird in Prevayler kein Allheilmittel finden, aber einen guten Verbündeten für eine einfache und vor allem performante Umsetzung in eigenen Projekten.

Offizielle Projekt-Homepage: http://www.prevayler.org

Alle Assertions in JUnit beginnen mit dem Schlüsselwort assert, folgende stehen uns dabei zu Verfügung:

• assertEquals
• assertNull
• assertSame
• assertTrue
• assertArrayEquals

Analog zu diesen Funktionen gibt es auch die entsprechenden negierenden Funktionen

• assertNotNull
• assertNotSame
• assertFalse

Die einzelnen Funktionen befinden sich alle in der Klasse Assert im Paket junit.framework. Neuere Funktionen befinden sich in org.junit. Die JavaDoc zu Junit kann man auf der offiziellen Website von JUnit finden.

static void assertEquals([String message], expected, actual)

assertEquals wird am Häufigsten verwendet. Die Funktion überprüft ob der Erwartungswert expected dem tatsächlichen Wert actual entspricht. Der Test schlägt fehl, wenn sich die beiden Werte gleichen. Möchte man eine eigene Nachricht definieren, welche bei Fehlschlagen des Tests angezeigt wird, so kann man das über den optionalen Parameter message angeben. Die Parameter expected und actual können beliebige Datentypen aufnehmen, von primitiven Datentypen wie int oder boolean bis zu allen Objekten die in Java erstellt werden. Werden Arrays miteinander verglichen wird nicht der Inhalt der Arrays, sondern lediglich die Referenz auf die Arrays zum Vergleich verwendet.

static void assertEquals([String message], expected, actual, tolerance)

Eine Besonderheit stellt der Vergleich von Fließkommazahlen dar, da mit ihnen nicht immer exakte Werte verglichen werden können. Das wird hauptsächlich durch die begrenzte Anzahl von Dezimalstellen nach dem Komma und den nach sich ziehenden Rundungs- und Berechnungsfehlern verursacht. Zum Ausgleich bietet asserEquals den Wert tolerance an, welcher die Genauigkeit nach dem Komma angibt. Gibt man für tolerance zum Beispiel den Wert 0.001 an, dann werden nur die letzten 3 Stellen nach dem Komma berücksichtigt. 0.01 wären 2 Stellen 0.000001 wären 6 Stellen.

static void asserNull([String message], java.lang.Object object)

assertNull überprüft ob ein Objekt null ist. Wie auch bei den anderen Assertions kann eine benutzerdefinierte Nachricht über den optionalen Parameter message angegeben werden. Analog dazu gibt es die Methode assertNotNull, welche überprüft ob das übergebene Objekt nicht null ist.

static void assertSame([String message], expected, actual)

Diese Methode überprüft ob zwei Objeke gleich sind. Dabei wird nicht überprüft ob die Inhalte, sondern ob die Objekttypen übereinstimmen. Wie auch bei assertNull das Gegenteil mit assertNotNull getestet werden kann, gibt es für diese Funktion den Gegenspieler asserNotSame.

static void assertTrue([String message], boolean condition)

Hier wird geprüft ob die Bedingung condition true ergibt. Das kann ein arithmetischer Ausdruck sein, aber auch ein Funktionsaufruf. Der Gegenspieler hierzu ist assertFalse, welcher (Überraschung) überprüft ob die angegebene Bedingung false ergibt. message ist, wie bei den vorherigen Funktionen, wieder der optionale Parameter mit welchem man eine benutzerdefinierte Nachricht angeben kann.

static void assertArrayEquals([String message], expecteds, actuals)

Wie schon erwähnt ist es nicht möglich die Inhalte von Arrays über die Funktion assertEquals zu vergleichen. Dafür gibt es die Funktion assertArrayEquals. Diese funktioniert genau gleich wie assertEquals, vergleicht jedoch die einzelnen Inhalte der Arrays. Diese Funktion steht erst ab Version 4.3 der JUnit API zur Verfügung.

static void fail([String message])

Eigentlich ist diese Funktion nicht wirklich eine Assertion, da keine Werte getestet werden. Der Test schlägt mit dieser Methode automatisch fehl und wird häufig dazu verwendet um Zweige des Programms zu testen, welche eigentlich nie erreicht werden dürften.

Mit diesen Funktionen als Handwerkszeug sind die meisten Testfälle abgedeckt. Im nächsten Teil der Serie werden wir Best Practices und wie getestet werden sollte besprechen.

Schritt 1: Erstellen eines JUnit-Projekts in Eclipse

Abbildung 1: Neues Projekt erstellen

Abbildung 2: Build Einstellungen

Abbildung 3: Auswahl der Bibliothek

Abbildung 4: JUnit-Version

Erstellen Sie ein neues Java-Projekt in Eclipse und vergeben Sie einen sinnvollen Namen (Abbildung 1). Unser Beispiel wird aus simplen Rechenfunktionen bestehen. Wichtig ist, das in den Build-Einstellungen im Reiter Libraries die JUnit-Bibliothek eingebunden wird. Dazu wählt man Add Library … (Abbildung 2) und dann JUnit (Abbildung 3). Im darauffolgenden Fenster kann die Version von JUnit ausgewählt werden. In unserem Fall nehmen wir die Version 4 (siehe Abbildung 4).

Schritt 2: Anlegen eines Tests

Abbildung 5: JUnit in Eclipse

Wir legen uns die Klasse Rechnen.java (Quellcode 1) in unserem Projekt an. Das wird die Klasse sein, welche die zu testenden Funktionen enthält. Wir erstellen uns eine Methode names addiere(). Die Funktion empfängt zwei Zahlen addiert diese beiden und gibt diese zurück. Wir werden diese Klasse später noch um weitere Funktionen erweitern. Wie ich in Teil 1 der Artikelreihe schon erwähnt habe, werden für gewöhnlich die Tests zuerst geschrieben und dann die Funktion implementiert.

Als nächstes erstellen wir uns die Klasse TestRechnen.java (Quellcode 2). Diese erbt von der JUnit-Klasse TestCase. Wir erzeugen eine neue Instanz von Rechnen, deren Funktionen wir Testen wollen. Die Methode, welche den Test ausführt nennen wir testAddiere(). Alle Methoden, welche einen Test ausführen, müssen auch mit test beginnen. Innerhalb der Funktion wird assertEquals aufgerufen. Diese Funktion wird von JUnit gestellt. AssertEquals überprüft ob der Wert den man erwartet der Gleiche ist, welcher von der zu testenden Funktion zurückgegeben wird. In unserem Beispiel erwarten wir das der Aufruf der Methode addiere mit den Zahlen 1 und 1, 2 ergeben.

Quellcode 1: Rechnen.java
package de.zeroseven.tutorials;

public class Rechnen {

	public int addiere(int zahl1, int zahl2) {
		return zahl1 + zahl2;
	}
}

Um unseren Test nun auszuführen, klicken wir mit Rechts auf TestRechnen und wählen Run As … -> JUnit-Test. In dem sich darauf öffnenden (Abbildung 5) Fenster, werden nun alle Tests angezeigt. Die allerwichtigste Anzeige ist der große grüne Balken, welcher anzeigt das alle Tests ohne Fehler durchlaufen worden sind. 1 und 1 sollte ja auch 2 ergeben. Um zu sehen, wie es aussieht wenn ein Test schief läuft, stellen Sie den Erwartungswert auf was Anderes als 2. Dann wird der grüne Balken rot angezeigt.

Quellcode 2: TestRechnen.java
package de.zeroseven.tutorials;

import junit.framework.TestCase;

public class TestRechnen extends TestCase {

	private Rechnen myRechnen = new Rechnen();

	public void testAddiere() throws Exception {
		assertEquals(2, myRechnen.addiere(1,1));
	}
}

Unterhalb des Balkens werden Details zum Schieflaufen des Tests angezeigt, wie zum Beispiel wo der Fehler aufgetreten ist. Was uns durch die Veränderung des Erwartungswertes angezeigt wird ist kein Fehler sondern ein Failure. Ein Fehler wird in JUnit als Error bezeichnet. Um dies zu provozieren fügen wir eine neue Testfunktion namens testError ein (Quellcode 3). Diese macht nichts anderes als eine Exception zu werfen. Ändern Sie den Erwartungswert wieder auf 2 und starten sie den Unit-Test neu. Nun wird ein Fehler und kein Failure mehr angezeigt.

Quellcode 3: Funktion die einen Error erzeugt
public void testError() throws Exception {
	throw new Exception("Irgendwas lief schief");
}

Das war unser erster einfacher Unit-Test. Im nächsten Teil der Reihe werde ich auf die unterschiedlichen Testmethoden wie assertEquals, welche JUnit schon mitbringt.

Ein Unit-Test beschreibt einen Test der den logischen Teil einer Software testet, der nicht syntaktisch oder aufgrund implementierter Fehlererkennung zu Fehlern führen kann. Ein Beispiel ist ein Algorithmus der 2 Zahlen addiert. Ein Unit-Test kann nun zum Beispiel überprüfen, ob richtig addiert wird, indem man dem Test Eingabeparameter und das zu erwartende Ergebnis mitgibt. Stimmt das errechnete Ergebnis nun mit dem zu erwartenden Ergebnis überein, so wird der Test erfolgreich durchlaufen. So können automatsich Zustände abgefangen werden, die häufige Fehlerquellen sind. Zum Beispiel die Eingabe von negativen Werten, Duplikaten oder null. Das Ergebniss kann entweder ein OK, ein Failure oder ein Error sein. Failures treten am häufigsten auf und beschreiben das “Fehlschlagen” des Tests. Dabei werden die Erwartungswerte des Tests nicht erfüllt. Ein Error tritt auf wenn ein Fehler auftritt, der ein “richtiger Softwarefehler” ist. So werden nach und nach alle Komponenten getestet. Ziel sollte es sein, das keine Funktion und Klasse als Produktionscode gesehen werden soll, bis nicht alle Tests erfolgreich durchlaufen werden.

Unit-Testing beeinflusst durch seine Modularität den gesamten Entwicklungsprozess. Fügt ein Entwickler weitere Änderungen zum Code hinzu, dann prüft er zuerst ob die Software alle Tests erfolgreich durchläuft und stellt somit sicher das später auftretende Fehler höchstwahrscheinlich an seiner Implementierung liegen.

Ich verwende in diesen Artikeln Eclipse das JUnit schon mit sich führt. Arbeitet man ohne Eclipse müssen die entsprechenden Klassenpfade und Bibliotheken angepasst werden. Auf www.junit.org kann man sich die aktuelle Version herunterladen und weitere Informationen zu JUnit erhalten.

In Teil 2 dieses Artikels werden wir nächste Woche unseren ersten Unit-Test schreiben und anwenden.

Field[] myFields = this.getClass().getDeclaredFields();

um auf die Methoden eines Objekts zugreifen zu können verwendet man

Method[] myMethods = this.getClass().getMethods();

wobei this durch eine beliebige Klasse ersetzt werden kann. Java verbietet es von Haus aus auf private Felder zugreifen zu können. Jedoch kann mit der Methode setAccessible(true) der Zugriff erlaubt werden. Mit diesen Werkzeugen an der Hand ist es nun ein Leichtes eine Methode zu schreiben, welche zur Laufzeit den Inhalt jedes beliebigen Objekts ausgeben kann.

Eine weitere interessante “Einsicht” ist die Rückverfolgbarkeit, von welcher Funktion aus eine Funktion aufgerufen wurde. Meinem Wissensstand nach gibt es leider in Java kein Bordmittel um auf diese Information zuzugreifen. Allerdings gibt es einen “Hack” um das zu bewerkstelligen. Jedesmal wenn eine Funktion aufgerufen wird, dann legt Java ein Element mit diversen Informationen, darunter auch den Namen der Funktion, auf seinen internen Verwaltungsstack. Wird die Funktion verlassen wird das Stackelement wieder vom Stack genommen. Dadurch ist zum Beispiel die Funktion printStackTrace() zur Ausgabe von StackTraces bei Exceptions möglich. Schaut man sich den Stack an, dann sieht man in welcher Reihenfolge Funktionen aufgerufen wurden. Diesen Umstand machen wir uns zum Nutzen und generieren in einer Funktion eine Standard-Exception. Diese beinhaltet natürlich den Stack zum Zeitpunkt zu dem die Exception generiert wrude.

Mit StackTraceElement stackElement = myException.getStackTrace()[n] greift man dann auf das n-te Element des Stacks zu. Um auszugeben welche Funktion die Funktion, in welcher die Exception erzeugt wurde, aufgerufen hat, wäre das das 1te Element also getStackTrace()[1]. Um den Namen einer Funktion auszugeben ruft man dann auf dem StackTraceElement die Funktion getMethodName() auf.

Durch die beiden oberen “Einsichten” lassen sich einige Funktionalitäten generalisieren und in eigene Klassen auslagern um bei Bedarf wieder darauf zuzugreifen. Zugegebenermassen ist die Methode über Exceptions auf den Stack zuzugreifen etwas dirty, funktioniert aber wunderbar und ermöglicht Funktionen die unnötige Tiparbeit ersparen. Ich zum Beispiel verwende diese Funktion zum Profiling und weiss dadurch immer welche Funktionen davon betroffen sind.

Bei der schnelleren Variante habe ich die drawImage()-Funktion des Graphics2D Kontextes eines BufferedImage verwendet, die es als Ausprägung mit Parametern zum skalierten Zeichnen gibt. Dabei wird auch der RenderingHint eingesetzt, der dafür zuständig ist, wie ein grafischer Kontext gerendert wird. Dabei muss dem Rendering-Hint ein Hint-Key und der Wert des Keys mitgegeben werden. Der Key gibt den Wert des zu beeinflussenden Rendering-Filters an, über den Wert des Keys stellt man den Algorithmus zur Neuberechnung ein. Für die Skalierung ist der Wert KEY_INTERPOLATION wichtig. Er gibt an wie die Interpolation, also die Neuberechnung der Pixel in einem Bild erfolgen soll. Dazu gibt es verschiedene Algorithmen, welche dafür verwendet werden können. Wer schon mal mit professionellen Bildbearbeitungstools gearbeitet hat, dem sollten die einstellbaren Algorithmen wie “bicubic interpolation” oder “nearest neighbor” zumindest namentlich ein Begriff sein. Von der Wahl des Algorithmus ist dann die Berechnungsgeschwindigkeit und die Qualität des Ergebnisses abhängig. Als Wert für KEY_INTERPOLATION stehen dabei folgende Werte aufsteigend in Qualität zur Verfügung

VALUE_INTERPOLATION_NEAREST_NEIGHBOR

VALUE_INTERPOLATION_BILINEAR

VALUE_INTERPOLATION_BICUBIC

Weitere Informationen zu Rendering-Hints gibt es wie immer in der API-Spezifikation. Es lohnt sich einen Blick in die Spezifikation der Rendering-Hints zu werfen, da noch andere Einstellungen beim Erzeugen oder Manipulieren von Bildern gemacht werden können.

Wie schon zu Beginn des Posts sollte man also auf getScaledInstance() verzichten und stattdessen den grafischen Kontext eines Bildes verkleinert oder vergrößert zeichnen, da der Geschwindigkeitgewinn im Vergleich erheblich sein kann und sich keine signifikanten Qualitätsunterschiede ergeben. Zudem ist über RenderingHints auch der gesamte Prozess einfach einzustellen.