Programmieren. JUnit-Tests. Heusch -- Ratz -- Institut für Angewandte Informatik

Transkript

1 Programmieren JUnit-Tests Heusch -- Ratz -- KIT Die Forschungsuniversität in der Helmholtz-Gemeinschaft

2 Testgetriebene Entwicklung (auch testgesteuerte Programmierung, engl. test-driven development (TDD) oder test first development) ist eine Methode, die häufig bei der agilen Entwicklung von Computerprogrammen eingesetzt wird. Bei der testgetriebenen Softwareentwicklung erstellt der Programmierer Software-Tests konsequent vor den zu entwickelnden Software-Komponenten. D.h. was die Komponenten leisten sollen, wird in Form von ausführbaren Tests spezifiziert ( ausführbare Spezifikation ). Die Testfälle werden als Grey-Box-Tests bezeichnet. Black-Box-Tests: Tests ohne Kenntnisse über die Interna des zu testenden Systems. White-Box-Tests: Tests auf Basis der Kenntnis des Codes. 2

3 Warum testgetriebene Entwicklung? Steigerung der Produktivität Verbesserung der Code-Qualität Bessere Überprüfbarkeit des Erreichens von Zielen Leichtere Wartbarkeit Quelle: 3

4 Iteratives Testen und Programmieren Der Zyklus des Testens und Programmierens: 1. Entwirf zunächst einen (oder einen weiteren) Test. (Es ist noch kein zugehöriger Code vorhanden.) 2. Schreibe gerade soviel Code, dass der Test gerade abläuft (jedoch noch fehlschlägt). 3. Schreibe gerade soviel Code, dass der Test korrekt durchläuft. Dieser Prozess wird so lange wiederholt, bis dem Entwickler keine sinnvollen weiteren Tests mehr einfallen. Die Zyklen werden durchgeführt bis der Code die durch die Tests spezifizierten Anforderungen erfüllt. Anschließend wird der Code in die einfachst-mögliche Form refaktorisiert. 4

5 Zyklus des Testens und Programmierens Füge einen Test hinzu Neuer Test schlägt fehl Refaktorisiere den Code Schreibe etwas Code Alle Tests laufen durch 5

6 Struktur des Projektverzeichnisses Bisher: zumeist ein Verzeichnis für Quellcode ( src ) Test-Klassen sollten jedoch nicht im gleichen Verzeichnis wie normaler Quellcode abgelegt werden. Software muss nur bei der Entwicklung getestet werden. Ausgeliefert werden compilierte Versionen, ohne Test-Klassen. Separater Quellcode-Baum für die Test-Klassen im Projekt-Verzeichn. Dieser Ordner wird üblicherweise test genannt. Hier die normalen Klassen Hier alle Test -Klassen 6

7 JUnit Erster Test in NetBeans (1) Projekt anlegen (mit leerer zu entwickelnder Klasse) Im Projekt einen JUnit Test anlegen (Quellcodeverz. etc.) 7

8 JUnit Erster Test in NetBeans (2) Neuen Test anlegen Name der Test-Klasse Verzeichnis des Quellcods der Test-Klassen im Projekt Package für Test-Klasse Quellcode-Baum test wird automatisch erzeugt 8

9 JUnit Erster Test in NetBeans (3) Von der IDE erzeugtes Grundgerüst der Test-Klasse Import von JUnit-Klassen Einfache Klasse, ohne Vererbung Annotationen vor Methoden (Name des entspr. Annotation-Type) Test- Methoden hier einfügen 9

10 JUnit Erster Test in Eclipse (1) Projekt anlegen (mit leerer zu entwickelnder Klasse) Quellcode-Verzeichnis für Test-Klassen anlegen 10

11 JUnit Erster Test in Eclipse (2) In das Projekt einen JUnit Test Case einfügen 11

12 JUnit Erster Test in Eclipse (3) Neuen Test anlegen JUnit-Version wählen (wir beziehen uns auf JUnit 4) Quellcode-Verzeichnis der Test-Klassen ( test auswählen!) Package für Test-Klasse Name der Test-Klasse Zu erstellende (leere) Hilfsmethoden 12

13 JUnit Erster Test in Eclipse (4) JUnit benötigt die entsprechenden Bibliotheken für JUnit 4 im Projekt-Classpath. Eclipse frägt beim Erstellen der Test-Klasse, ob diese dem Projekt hinzugefügt werden sollen: 13

14 JUnit Erster Test in Eclipse (5) Von der IDE erzeugtes Grundgerüst der Test-Klasse Import von JUnit-Klassen Einfache Klasse, ohne Vererbung Annotationen vor Methoden (Name des entspr. Annotation-Type) Erste Test-Methode 14

15 Die Annotationen und ihre Bedeutung public void (expected = public void public void public static void public static void public void method() Beschreibung Kennzeichnet eine Methode als Test-Methode (einzelner Test). Ein Test wird entweder bestanden ( passed ) oder er schlägt fehl ( failed ). Schlägt fehl, wenn die Methode nicht die genannte Exception wirft. Schlägt fehl, wenn die Methode länger als 100ms Laufzeit benötigt. Diese Methode wird vor jedem einzelnen Test ausgeführt. Sie wird verwendet, um die Testumgebung vorzubereiten, z.b.um Klassen zu initialisieren oder Eingabewerte einzulesen. Diese Methode wird nach jedem einzelnen Test ausgeführt. Sie wird zum Aufräumen verwendet, z.b. um Defaultwerte wiederherzustellen oder temporäre Daten zu löschen. Sie kann auch zum expliziten Freigeben von reserviertem Speicher verwendet werden. Diese Methode wird (einmalig) zu Beginn des gesamten Tests ausgeführt. Sie wird insb. für zeitaufwändige Aktivitäten verwendet, z.b. für das Herstellen einer Datenbankverbindung oder das Lesen großer Datenmengen. Die annotieren Methoden müssen static sein! Diese Methode wird (einmalig) nach Beendigung aller Tests ausgeführt. Sie wird zum allgemeinen Aufräumen verwendet, z.b. das Schließen einer Datenbankverbindung. Die annotieren Methoden müssen static sein! Diese (Test-)Methoden werden bei Tests ignoriert. Dies könnte nötig sein, wenn nach einer Codeänderung dieser Test noch nicht adaptiert wurde, oder wenn ein Test aufgrund seiner langen Ausführungszeit (temporär) ausgeschlossen werden soll. 15

16 Beispiel: Bankkonto (1) Es soll eine Klasse Account für ein einfaches Bankkonto erstellt werden. Die Methoden der Klasse sollen mit Hilfe von JUnit-Tests überprüft werden. Klasse Account zu Beginn der Tests: public class Account { private long balance; // Kontostand in Eurocent public Account(long initialbalance) { this.balance = initialbalance; public void setbalance(long balance) { this.balance = balance; 16

17 Beispiel: Bankkonto (2) Für Exceptions gibt es außerdem die Klasse AccountException (hier im gleichen Paket wie die Klasse Account). public class AccountException extends Exception { public AccountException(String msg) { super(msg); 17

18 Beispiel Bankkonto: Methoden entwickeln Es sollen nun die folgenden Methoden der Klasse Account implementiert und getestet werden: public long getbalance() public void inpayment(long amount) throws AccountException // Diese Methode wird Gegenstand einer Übung public void outpayment(long amount) throws AccountException // Diese Methode wird Gegenstand einer Übung public boolean isbalancepositive() Dabei sollen ungültige Parameterwerte jeweils zu einer AccountException führen. 18

19 Test vorbereiten Rahmen der Test-Klasse (zusätzl. Imports und Angaben): import org.junit.runner.runwith; import org.junit.runners.junit4; import <package-name-of-account>.account; import // Kennzeichnet die Klasse als JUnit4-Test public class AccountTest { private static Account account; // Account-Obj. soll getestet werden! private static final long INIT_ACCOUNT_BALANCE = 4711; public AccountTest(){ // Hier werden dann die Methoden für die Tests // (inkl. der zugehörigen Annotationen) eingefügt. 19

20 (in Klasse AccountTest). Für diesen einfachen Fall wäre das nicht unbedingt nötig. Hier wird nur ein neues Account-Objekt erzeugt und eine Info auf der Konsole ausgegeben. /** * (Einmalige) Initialisierung, vor allen Tests. * Ein Konto-Objekt wird erzeugt. Die Methodennamen */ sind frei public static void setupaccount() { AccountTest.account = new Account(INIT_ACCOUNT_BALANCE); System.out.println("Account created."); wird hier nicht verwendet 20

21 Hier wird der Standard-Kontostand gesetzt. /** * Initialisierung vor jedem einzelnen Test. * Der Kontostand wird auf einen definierten Betrag gesetzt. * * Man könnte auch hier (statt in ein * neues Konto anlegen. public void setup() { account.setbalance(init_account_balance); wird hier nicht verwendet Methodennamen sind frei wählbar 21

22 Test für die Methode getbalance() Testen: Liefert die Abfrage des Kontostands den korrekten Wert (d.h. den public void testaccountbalance() { assertequals(init_account_balance, account.getbalance()); // assertequals: Methode der Klasse org.junit.assert 22

23 Tests für die Methode inpayment() Testen: Werden zwei sequentielle Einzahlung als Summe public void inpaymenttest() throws AccountException { account.inpayment(500); account.inpayment(200); assertequals(init_account_balance , account.getbalance()); Testen: Führt eine negative Einzahlung zu einer (expected=accountexception.class) public void inpaymentnegativetest() throws AccountException { account.inpayment(-200); Testen: Ändert eine Einzahlung von 0 den Kontostand public void inpaymentzerotest() throws AccountException { long balancebefore = account.getbalance(); account.inpayment(0); assertequals(balancebefore, account.getbalance()); 23

24 assert-methoden ( Behauptungen, Bestätigungen ) der Klasse org.junit.assert Wertvergleich: assertequals, assertthat Arrayvergleich: assertarrayequals Referenzvergleich: assertsame, assertnotsame Bedingung: assertfalse, asserttrue null oder nicht null: assertnull, assertnotnull Zu Details siehe Literatur auf der letzten Folie. Auf jeden Fall fehlschlagen: fail, z.b. fail("not implemented yet."); 24

25 Wir erinnern uns: Der Test für getbalance() Testen: Liefert die Abfrage des Kontostands den korrekten Wert (d.h. den public void testaccountbalance() { assertequals(init_account_balance, account.getbalance()); // assertequals: Methode der Klasse org.junit.assert 25

26 Implementierung von getbalance() (1) Leere Implementierung der Methode getbalance() in der Klasse Account : public long getbalance() { return 0; Beim Ausführen von AccountTest schlägt der Test fehl: NetBeans- Ausgabefenster 26

27 Implementierung von getbalance() (2) Erweiterung von getbalance(): public long getbalance() { return balance; Diese Erweiterung lässt den Test bestehen: NetBeans- Ausgabefenster 27

28 Wir erinnern uns: die Tests für inpayment() Testen: Werden zwei sequentielle Einzahlung als Summe public void inpaymenttest() throws AccountException { account.inpayment(500); account.inpayment(200); assertequals(init_account_balance , account.getbalance()); Testen: Führt eine negative Einzahlung zu einer (expected=accountexception.class) public void inpaymentnegativetest() throws AccountException { account.inpayment(-200); Testen: Ändert eine Einzahlung von 0 den Kontostand public void inpaymentzerotest() throws AccountException { long balancebefore = account.getbalance(); account.inpayment(0); assertequals(balancebefore, account.getbalance()); 28

29 Implementierung von inpayment() (1) Leere Implementierung von inpayment(): public void inpayment(long amount) throws AccountException { Beim Ausführen von AccountTest schlagen zwei Tests fehl: Eclipse- Ausgabefenster Hinweis: Die Reihenfolge der Tests im Testergebnis-Fenster stimmt i. Allg. nicht mit der Reihenfolge der Tests im Programm überein. 29

30 Implementierung von inpayment() (2) Einfache Implementierung von inpayment(): public void inpayment(long amount) throws AccountException { this.balance += amount; Mit dieser Implementierung schlägt nur noch ein Test fehl: 30

31 Implementierung von inpayment() (3) Eine Erweiterung: public void inpayment(long amount) throws AccountException { if ( amount >= 0 ){ this.balance += amount; else { throw new AccountException("No negative inpayments!"); Mit dieser Erweiterung werden alle Tests bestanden: 31

32 Aufgabe Implementieren Sie die Klasse Account und die Tests aus diesen Folien nach! Schreiben Sie in der Klasse AccountTest (jeweils mehrere) Tests für die Methoden: public void outpayment(long amount) throws AccountException public boolean isbalancepositive() Erweitern Sie die Klasse Account um leere (bzw. minimale) Implementierungen dieser Methoden. (Aus pragmatischen Gründen kann dies auch schon vor dem Schreiben der Tests gemacht werden, damit die Tests vom Compiler ohne Fehleranzeige akzeptiert werden.) Testen und implementieren Sie nun Schritt für Schritt diese Methoden! 32

33 Literatur NetBeans-Tutorial: Writing JUnit Tests in NetBeans IDE Informationen in NetBeans: Help > Javadoc References > JUnit API > Packages: org.junit und Unterpakete Eclipse-Tutorial: Java Unit testing with JUnit 4.x in Eclipse 33