= JUnit =

JUnit (http://junit.sourceforge.net) ist ein Framework für [Unittests|http://en.wikipedia.org/wiki/Unit_testing] in [Java]. Im Grunde genommen ist JUnit das einzige und überall benutzte Framework zu diesem Thema. Daher gibt es eine Unzahl an Artikeln hierzu sowie eine anständige Integration in alle wichtigen IDEs (z.B. in [Eclipse]).



== Warum Tests? ==

Auch zu dieser Frage gibt es bereits viele Artikel im Netz. Ein Test sorgt dafür, daß die getestete Funktionalität auf jeden Fall in allen späteren Versionen noch funktioniert. Bei Projekten, die etwas größer werden oder auch deren Lebensdauer etwas größer ist, kann man so sicher sein, daß man bei einer späteren Änderung nichts kaputt macht, was woanders gebraucht wird. Auch ist es möglich, den bestehenden Code zu überarbeiten (Refactoring) und immer zu wissen, daß die eigentliche benötigte Funktionalität nicht geändert wurde. Alle Tests sollten nach jeder kleineren oder größeren Änderung am Programm (am besten automatisch) gestartet werden, um die Integrität des Codes zu gewährleisten.

Man kann Tests vor dem eigentlichen Code erstellen (man beschreibt dadurch sozusagen zuerst die Funktion, bevor man sie implementiert), man kann aber auch eine abgespeckte Philosophie verfolgen und nur an schwierigen Stellen sowie bei festgestellten Bugs Tests schreiben.



== Einstieg ==

Wer mit JUnit anfängt, sollte darauf achten, daß bis ca. 2007 JUnit 3.x aktuell war, aber inzwischen JUnit 4.x der Standard ist. Hier hat sich im Prinzip alles geändert. Glücklicherweise haben die Entwickler jedoch auch die Paketnamen geändert, so daß man das schnell merkt. Wer also in Beispielen import-Befehle sieht, die sich auf "junit..." beziehen, hat einen veralteten Artikel, weil die 4.x-Klassen in "org.junit..." stehen.

Für den Anfänger empfehle ich das "Cookbook" auf der Webseite des Projektes. Eigentlich ist darin für den Anfang alles wichtige gesagt.



== Spezialisten-Tips ==

Da über JUnit eigentlich alles normale bereits irgendwo im Internet gesagt worden ist und jeder hier wohl Google bedienen kann, möchte ich hier keine ausführliche Anfänger-Einführung präsentieren (Wer meint, wir brauchen sowas, kann das natürlich gerne hier ändern). Stattdessen möchte ich hier die Dinge aufzählen, die nicht so gut dokumentiert sind.

=== Entwickler-Dokumentation ===

Dafür, daß mit JUnit 4.x vor relativ kurzer Zeit das ganze Framework quasi neu geschrieben worden ist und dafür, daß sich ganze Generationen von hochfliegenden IT-Theoretikern am "Test Driven Development" hochziehen, ist die Entwickler-Dokumentation grauenhaft, nämlich eigentlich nicht vorhanden. Wer etwas tiefer einsteigen will, sollte den Quellcode bzw. die Javadoc zur Hilfe nehmen. Allerdings ist letztere auf der Webseite nicht zu gebrauchen, weil sie entweder für JUnit 3.x ist oder keine protected Klassen enthält oder beides. Also die Sourcen herunterladen und neu erstellen.

=== Suiten ===

Eine Suite ist ein Test, der seinerseits mehrere andere Tests aufruft und diese damit sozusagen "bündelt". Dies ging auch unter 3.x schon recht gut und war dort ziemlich übersichtlich und logisch integriert. Die Implementation in 4.x ist auch sehr übersichtlich und logisch aber seltsamerweise nirgendwo dokumentiert. Ich habe in der [Javadoc|http://junit.sourceforge.net/javadoc_40/index.html] erst einen Hinweis finden müssen. So kann man z.B. mit folgender Klasse (ja - das ist alles) die zwei genannten Testklassen "zusammenfassen".

{{{
@RunWith(Suite.class)
@SuiteClasses( { GUITest.class, UnitTest.class })
public class SuiteTest {

}
}}}

Was ist nun der Sinn so einer Suite? Wenn man wirklich viele Tests hat, kann man diese hiermit gruppieren und dann z.B. nur die GUI- oder nur die Datenbank-Tests durchführen. Oder man stellt Tests, die sehr lange dauern, auf diese Art zusammen, weil man sie vielleicht nur ab und zu über Nacht laufen lassen will, während die anderen Tests öfter gestartet werden.

==== Suiten in [Eclipse] ====

[Eclipse] erkennt die Suiten von JUnit 4.x übrigend bereits vollständig und stellt diese im JUnit-View in einer Baumansicht als zusätzlichen Ast dar (Natürlich kann man Suites auch schachteln, d.h. in einer Suite kann eine andere Suite als Testklasse angegeben werden). Dadurch wird die Anzeige dieses Views bei einer grossen Anzahl von Tests sehr viel übersichtlicher. Leider muss man jedoch auf die Annehmlichkeit verzichten, daß Eclipse einem normalerweise alle Tests in einem Projekt oder einem Verzeichnis automatisch startet. Dabei merkt Eclipse nämlich nicht, daß ein Test bereits durch eine Suite aufgerufen wird und führt ihn so doppelt aus. Stattdessen habe ich von Hand eine Suite geschrieben, die alle meine Tests aufführt und muss dann halt darauf achten, einen neuen Test dort nicht zu vergessen.

=== eigene Runner ===

Es ist möglich, eigene Testrunner zu schreiben und die Art und Weise, wie Tests ausgeführt werden, anzupassen. Hierzu werde ich evtl. in Bälde ein Beispiel geben können.

=== Testen von Swing-Applikationen ===

Zum Test von Swing-Applikationen gibt es mehrere Bibliotheken (siehe unten). Alle, die ich bisher getestet habe, führen dazu, daß die Applikation normal geöffnet wird und scheinbar "magisch" von dem Testprogramm bedient wird. Dies hat den Nachteil, daß man während des Tests seine GUI nicht benutzen darf, da man sonst z.B. den Focus verstellen würde. Das erschwert natürlich leider auch automatisierte Tests z.B. im Hintergrund oder vor einem Commit.



== Links ==

* http://www.junit.org - Die erste Anlaufstelle, wenn es um Tests in Java geht
* http://www-128.ibm.com/developerworks/java/library/j-cwt02095/ - Artikel über Hansel (Code Covering). Interessant auch unten die Links zu anderen Tools.
* http://dbunit.sourceforge.net - Tests mit Datenbanken. Interessantes Tool sowie auch einige gute Links zu Artikeln zum Thema
* https://jmockit.dev.java.net/ - Wenn man Test-Stummel braucht: Mock-Objekte, die reale Klassen (z.B. den Datenbankzugriff) ersetzen
* Unit-Testing unter Swing
** http://www.java-source.net/open-source/testing-tools - Übersicht über Testing Tools
** http://www.javaworld.com/javaworld/jw-11-2004/jw-1115-swing.html - guter Artikel, wie man es selber machen kann
** http://www.uispec4j.org/ - uispec4j hat eine sehr schöne API (die Tests sind einfach zu lesen). Es arbeitet, ohne echte Fenster zu öffnen, das ist schneller, kann aber nicht alles (z.B. Focus)
** http://jfcunit.sourceforge.net/ - jfcunit wird oft genannt, es funktioniert bei mir sehr gut. Es steuert "live" Fenster und man kann sogar mit dem Debugger zusehen, wie die GUI sich bewegt
*** http://www.devx.com/Java/Article/9614/0/page/2 - Artikel über jfcunit
** https://swingunit.dev.java.net/ - swingunit arbeitet mit XMl-Dateien zur Testkonfiguration
** http://jemmy.netbeans.org/ - Jemmy (wird in Netbeans verwendet)

-- ThomasBayen

[{Tag Java}]