Das automatisierte Testen mit JUnit

Transkript

1 Das automatisierte Testen mit JUnit SWT Seminar (SS03) Ausgearbeitet von Sundui Baatarjav Am Fachbereich Informatik der TU-Berlin

2 EINLEITUNG 3 JUNIT - FRAMEWORK 4 Aufbau und Struktur 4 TestCase 4 Assert 6 TestRunner 6 Testfixture 8 TestSuite 8 Testen von Exception 10 DIE ERWEITERTEN JUNIT-FRAMEWORKS 11 JXUni -Framework 11 JFCUnit 11 XMLUnit 12 Castus 12 ZUSAMMENFASSUNG 12 QUELLENVERZEICHNIS 12

3 Einleitung Testen ist wichtig bei der Softwareentwicklung. Leider haben die meisten Projekte wenig Zeit zum Testen. Es gibt verschiede Testansätze. z.b. Modultest, Spezifikationstest, Integrationstest etc. In dieser Ausarbeitung wird Modultest vorgestellt und welches Werkzeug unterstützt Modultest. Die zentrale Testaufgabe der Programmierer sind jedoch die so genannten Unit Tests, auch Modultests genannt. Unit Tests werden in der Softwareentwicklungsprozess auf unterschiedliche Phasen eingesetzt. z.b. Bei der V-Modell 1 wird Unit Test in der Phase Modultest eingesetzt. XP 2 ist leichtgewichtige Softwareentwicklungsprozess, in der als erstes Unit Tests vor der eigentlichen Applikationscode geschrieben werden. Unit Tests konzentriert sich nicht auf das gesamte System, sondern auf einzelne Einheiten (Moduls) des Systems. Jedes einzelne Stück Code ist getestet. Dadurch werden Änderungen, die vorhandene Funktionalität zerstören, sofort entdeckt. Für die Unit Tests besteht die Forderung zur völligen Automatisierung. Ohne Automatisierung sind Unit Tests in der Praxis unvorstellbar, weil Unit Tests unzählige Male pro Tag ausgeführt werden. Die Sprache zur Testspezifikation ist die Programmiersprache selbst. Es gibt zwei Möglichkeiten, um die Applikationsklasse zu testen: Statische Methode: für jede Klasse eine statische Methode mitzugeben, die eigene Tests ausführt. Eigene Tester-Klasse: für jede Klasse gibt es eine eigene Tester-Klasse, die die Funktionalität der Klasse testet. Diese beiden Varianten haben Vor- und Nachteile. Statische Methode Eigene Tester-Klasse Vorteile Zugriff auf private Teile der Klasse möglich. Leichte Wiederverwendungen des Testcode in Unterklassen Trennung von Anwendungscode und Testcode. Strukturierung des Testcode unabhängig von Klassenstruktur Nachteile Keine Trennung von Anwendungscode und Testcode Zusätzliche Klasse notwendig. Kein Zugriff auf private Teile der Klasse möglich Es gibt Unit Testing Frameworks für die meisten Programmiersprachen. z.b. CppUnit für C++,.NUnit für.net Sprachen. Im Folgenden wird JUnit-Framework näher vorgestellt. 1 V-Modell nach Böhm 2 Extreme Programming

4 JUnit - Framework Aufbau und Struktur JUnit (Java for Unit Testing) bietet ein in Java geschriebenes Framework zur Automatisierung von Unit Tests an. Dieses Open-Source-Framework zur Automatisierung von Unit Tests in Java wurde von Kent Beck und Erich Gamma entwickelt. Die aktuelle Version von JUnit 3.8 ist über die Website verfügbar. Diese Klassen spielen wichtige Rolle in JUnit-Framework: TestRunner, um Tests auszuführen. TestCase, um Testfall zu erstellen. TestSuite, um Testfälle zusammenzufassen. Assert, um Testfall zu überprüfen. TestResult, um Testergebnisse zu sammeln. In der Abbildung 1 wird gezeigt, wie diese Klassen miteinander in Verbindung stehen. Abbildung 1 TestCase Die Testfälle werden in eigenen Klassen definiert und die Testklasse muss von der Klasse junit.framework.testcase abgeleitet werden. Damit werden der Testcode und der Applikationscode getrennt behandelt. Wichtig ist, dass die Ausführung des Testfalles keine

5 Auswirkung auf andere Testfälle hat. Der Testfall wird in der Methode, deren Name mit test anfängt, geschrieben. Als kleines Beispiel haben wir eine Klasse Money 3. Diese Klasse besitzt das Attribute amount,das den Geldbetrag darstellt, und die Methode getamount(), die den Geldbetrag ausgibt, und add(int i), die den Geldbetrag um i erhöht. Beispiel: Klasse Money public class Money { private double amount; public Money(int amount) throws Exception { if (amount < 0) { throw new Exception( Grösser als NULL sein! ); this.amount = amount; public double getamount() { return this.amount; public void add(int i) { this.amount +=i; Die Klasse MoneyTest ist abgeleitet von TestCase und Testklasse für die Klasse Money public class MoneyTest extends junit.framework.testcase Meistens werden alle public Methoden von der Applikationsklasse getestet. Nun schreiben wir Testfälle: import junit.framework.*; public class MoneyTest extends TestCase { public MoneyTest(String name) { super(name); public void testgetamount() throws Exception { Money money = new Money(10); asserttrue(money.getamount(), 10); public void testadd() throws Exception { Money money = new Money(10); money.add(10); assertequals(money.getmoney(), 20); public void testconstructor() throws Exception { public static void main(string[] args) { junit.swingui.testrunner.run(moneytest.class); 3 aus dem JUnit-Homepage

6 Assert Bestimmte Eigenschaften von Testobjekt werden auf Übereinstimmung mit unseren Erwartungen überprüft. Die Klasse Assert bietet sämtliche assert-methoden an, die zur eindeutigen Überprüfung der Testergebnisse dienen: asserttrue( boolean condition) verifiziert, ob eine Bedingung wahr ist. assertequals(object expected, Object actual) verifiziert, ob zwei Objekte gleich sind. ( Der Vergleich erfolgt in JUnit über die equals Methode.) assertfalse(boolean conditon) verifiziert, ob eine Bedingung falsch ist. assertnull(object object) verifiziert, ob eine Objektreferenz null ist. assertnotnull(object object) verifiziert, ob eine Objektreferenz nicht null ist. assertsame(object expected, Object actual) verifiziert, ob zwei Objekte gleiche Referenzen haben. assertnotsame(object expected, Object actual) verifiziert, ob zwei Objekte nicht gleiche Referenzen haben. fail() Testfall einfach fehlschlägt. ( benutzt meisten Testen von Exception) Die Klasse TestCase ist von der Klasse Assert abgeleitet. TestRunner JUnit - Framework bietet drei unterschiedliche TestRunner-Klassen, um die Tests auszuführen: a) junit.textui.testrunner, der die Testergebnisse auf dem Konsule schreibt. b) junit.awtui.testrunner, ein einfaches AWT-basiertes graphisches Tool. c) junit.swingui.testrunner, ein komplexeres Swing-basiertes graphisches Tool. Nun führen wir unsere Testklasse mit diesen drei TestRunner aus. a) junit.textui.testrunner #java -cp junit.jar;. junit.textui.testrunner MoneyTest Time: 0,01 OK (3 tests) Jeder Punkt der Ausgabe zeigt uns einen erfolgreich ausgeführten Test; dazu hätten wir noch die Testausführungszeit, das Gesamtergebnis (OK) und die Anzahl der Tests. Fehlgeschlagene Tests hätten sich als F oder E in der Textausgabe bemerkbar gemacht und das Gesamtergebnis geändert. ( F entspricht Failure und E entspricht Error, aber dazu später mehr) b) junit.awtui.testrunner #java -cp junit.jar;. junit.awtui.testrunner MoneyTest In der Abbildung 2 junit.awtui.testrunner wird gezeigt.

7 Abbildung 2 Der grüne Balken zeigt, dass die Tests erfolgreich abgelaufen sind. Wenn der Balken rote Farbe hätte, würde dann bedeuten, dass die Tests fehlgeschlagen sind. c) junit.swingui.testrunner #java -cp junit.jar;. junit.swingui.testrunner MoneyTest In der Abbildung 3 wird junit.swingui.testrunner gezeigt. Abbildung 3

8 Wie junit.awtui.testrunner, zusätzlich kann man Testhierarchie sehen. Testfixture In der Klasse MoneyTest kommt dieses Testobjekt Money money = new Money (10) an mehreren Stellen öfter vor, d.h. dieses Testobjekt wurde an mehreren Stellen dupliziert. Dies ist typisch für eine Menge von Tests, die sich auf eine konkrete Komponente beziehen. Meistens wird nicht nur ein Objekt, sondern ein ganzes Geflecht von Objekten erzeugt, das für alle Testfälle einer Testklasse den Ausgangszustand darstellt, genannt auch Fixture. JUnit erlaubt es uns, den Code, der zur Erstellung der Fixture benötigt wird, in die Methode setup() auszulagern. Die Methode setup() wird vor jeden test-methoden aufgerufen. JUnit bietet die Möglichkeit, nach dem Ausführen eines Tests die Ressourcen in einer teardown()-methode freizugeben, die im setup() reserviert wurden, wie z.b. Dateien, Datenbankverbindung etc. In der Abbildung 4 wird die Funktionalität der Klasse TestCase gezeigt. Die setup() bzw. teardown() Methode werden unabhängig davon ausgeführt, ob die Test erfolgreich beendet oder fehlschlägt. Abbildung 4 Also sieht jetzt unser Code so aus: protected setup() throws Exception { money = new Money(10); public void testgetamount() { assertequals(money.getamount(), 10); public void testgetadd() { money.add(10); assertequals(money.getamount(), 20); protected teardown() { money = null; TestSuite Unser Ziel ist es, den gesamten Testprozess so weit möglich zu automatisieren, weil wir die Tests mehrmals ausführen. Die Testfälle können beliebig in Testsuiten zusammengefasst werden. Das Konzept ist in der Klasse junit.framework.testsuite verfügbar. Es gibt 2 Möglichkeiten, die Testsuite aufzubauen:

9 1. Wenn man suite() Methode in der Klasse TestCase nicht implementiert, werden die verschieden Testfälle von Testklasse in einer unbestimmten Reihenfolge aufgebaut. Die suite() Methode von der abgeleiteten Klasse TestCase benutzt. 2. Wenn man suite() Methode wird in der TestCase abgeleiteten Testklasse implementiert, dann kann man bestimmen, welcher Testfall zuerst aufrufen kann. Die Klasse TestSuite bietet addtestsuite(), addtest() Methode an, um die Reihenfolge zu bestimmen und Tests zusammenzubauen. In der Abbildung 5 werden die Klasse TestSuite und deren Zusammenhänge dargestellt. Abbildung 5 In unserem Beispiel: public class MoneyTest extends TestCase { public static Test suite() { Test suite= new TestSuite( MoneyTest"); suite.addtest(new TestCaseTest("testConstructor")); suite.addtest(new TestCaseTest("testGetAmount")); suite.addtest(new TestCaseTest( testadd )) return suite; public void static main(string[] args) { TestRunner.run(MoneyTest.suite()); Hier wird textuelle TestRunner benutzt. Ein Punkt entspricht einem Testfall, der erfolgreich abgelaufen ist. #java -cp junit.jar;. MoneyTest Time: 0,031 OK (3 tests) Testsuites können beliebig verschachtelt werden. Hier werden beispielsweise alle Testklassen von JUnit Framework in einem Testsuite zusammengefügt. package junit.tests;

10 import junit.framework.*; /** * TestSuite that runs all the JUnit tests */ public class AllTests { public static void main(string[] args) { junit.textui.testrunner.run(suite()); public static Test suite() { TestSuite suite= new TestSuite("Framework Tests"); suite.addtest(junit.tests.framework.alltests.suite()); suite.addtest(junit.tests.runner.alltests.suite()); suite.addtest(junit.tests.extensions.alltests.suite()); return suite; Auf dem Konsule zeigt, dass Tests unter folgenden Ergebnissen abgelaufen sind. #java -cp junit.jar;. junit.textui.testrunner junit.tests.alltests.... Time: 0,859 OK (91 tests) Testen von Exception Generell muss man zwischen zwei unterschiedlichen Kategorien von Fehlerfällen unterscheiden. Fehler, die wir vorhersehen und innerhalb der Applikation abfangen möchten. Die korrekte Behandlung solcher Fälle müssen wir in unseren Tests berücksichtigen. Fehler, die nicht vorhersehbar sind oder unerwartet entstanden sind. z.b. NullPointerException Das Auftreten erwarteter Fehler führt zur Rückgabe des richtigen Fehlerobjektes bzw. zum Werfen der richtigen Exception. In unserem Beispiel haben wir so implementiert, dass wir unsere Klasse mit grösser als Null Werten initialisiert, sonst wirft eine Exception zurück. Diese Zahl 0 teilt den Raum aller möglichen Testfälle in 2 Äquivalenzklassen. Ausschnitt aus Money-Klasse: public Money(int amount)throws Exception { if (amount < 0 ) { throw new Exception("Grösser als NULL sein!"); this.amount=amount; Dann sieht unsere Testklasse so aus: public void testconstructor() { try { Money money = new Money(-10); fail( Exception nicht aufgefangen ); catch (Exception e) { asserttrue( Exception aufgefangen!, true);

11 protect void setup() { try { money = new Money (10); catch (Exception e) { fail( Fehler auftreten ); Die erweiterten JUnit-Frameworks Das JUnit-Framework wird in unterschiedlichen Anwendungen erweitert, je nachdem in Abhängigkeit von Ziel und Zweck. z.b. JFC Unit ist ein Testframework für die swing basierten Anwendungen. Hier sind sämtliche erweiterte JUnit-Frameworks aufgelistet: JXUnit: (XML -Technologie basierte Testen) JunutEE: für den HTML-dokumentierten Servertest Jub: zur Generierung einfach Testtreiberbausteine JTestCase: zur Auslagerung der Testdaten vom Java-Treiber in XML-Dateien HttpUnit: zum black box Web Testing Cactus: zum server-seitige Unit Test JFCUnit: für Java Swing basierte Anwendungen XMLUnit: XML Dokumenten, deren Struktur und Inhalt werden getestet JXUni -Framework JXUnit ist Erweiterung von JUnit, wobei Testdaten und Testcode getrennt behandelt werden. Das JUnit-Framework unterstützt solche Mechanismen nicht, dass die Testdaten unabhängig von Testcode verwaltet werden. JXUnit basiert auf XML-Technologie und benutzt das Quick- Framework 4. Das Quick-Framework ist Kern von JXUnit und mächtig und flexibel. Quick verbindet Java- Objekte und XML-Daten. Das Quick-Framework ermöglicht es, die Java-Objekte einfach aus den XML-Dokumenten einfach zu erzeugen. Nicht nur die Testdaten werden in speziellen XML-Dokumenten geschrieben, sondern auch Teil der Logik von Testfällen beinhaltet spezielle XML-Dokumente. Die XML-Datei ist genannt JXU Datei (Java for XML Unit). Die aktuelle Version von JXUnit ist und steht unter der Adresse zur Verfügung. Die Tests können mit Hilfe der JUnit Standard-TestRunner (textual, awt oder swing) ausgeführt werden. JFCUnit 4 Quick: XML Made Easy

12 JFCUnit ist auch ein erweitertes JUnit-Framework für die Java Swing basierten Anwendungen. Mit JFCUnit werden getestet: Graphische Oberfläche bzw. Komponente (z.b. Window, Button) Interaktion zwischen den Komponenten. (z.b. Ereignisse) Die Testklasse muss auch von JFCTestCase abgeleitet sein. Die aktuelle Version ist jfcunit. 1.03, und unter zu erhalten. XMLUnit XMLUnit ermöglicht es, Inhalt und Struktur von XML zu überprüfen. XMLUnit ist über die Website zu erhalten. Man kann die Korrektheit des XML Dokuments anhand der DTD überprüfen, aber korrekte XML kann einen inkorrekten Inhalt haben. Da XMLUnit bietet dies zu überprüfen. z.b. <seminar>swt</seminar> aber nicht <seminar>flp</seminar> Castus Die Website von Castus ist Castus ist Testing-Framework für Testen von serverseitigem Java Code. z.b. Servlets, EJBs. Die Testfälle werden von der Client-Seite gesteuert und werden auf der Server-Seite ausgeführt. Zusammenfassung JUnit ist ein reines Java-Framework. Testsprache ist gleich Programmiersprache. JUnit bietet die Möglichkeit, dass Test Anwendungscode getrennt behandelt werden. JUnit erlaubt es, die Gemeinsamkeiten von Tests in eine setup()-methode auszulagern, die für jeden Test getrennt ausgeführt wird. Dadurch spielt die Reihenfolge der Testfällen keine Rolle. Die Tests können beliebig in Testsuiten zusammengefasst werden. JUnit liefert ein übersichtliches Testergebnis. JUnit scheint daher für die Unit Tests als Automatisierungswerkzeug geeignet. JUnit ist erweiterbar je nach dem Ziel und Zwecke. Trotzdem bleiben Testvorgehen und Testfallerstellung weiterhin abhängig von dem Entwickler. Tests unterstützen den Entwickler während der ganzen Entwicklung. Quellenverzeichnis

13