Unit Tests mit Junit 4 Dario Borchers
Agenda Warum testgetriebene Entwicklung von Software? - Motivation Was ist testgetriebene Entwicklung? - Prozess der testgetriebenen Entwicklung - Arten von Tests Junit 4 - Vorstellung - Integration in Eclipse - Testsuits, Testcases, Klassendiagramm - Phasen des Testens: Setup, Teardown etc. - Assertions, Arten von Fehlern Folie 2
Motivation Testen ist die Suche und das bewusste Provozieren von Fehlern Testen ist eine unliebsame Aufgabe - Fleißaufgabe - Suche nach der Nadel im Heuhaufen, stößt auf wenig Gegenliebe - Kanon von Ausreden - Ich habe dafür keine Zeit, Warum ich und nicht die Qualitätsabteilung? oder Ich bin Projektleiter, ich habe wichtigeres zu tun Der Prozess des Testens ist der letzte Schritt in der Entwicklung - Oft wird hier zuerst gespart - Software reift beim Kunden - Der Kunde ist Beta-Tester Folie 3
Motivation Folie 4
Motivation Ziel: Herrunterbrechen und Verlagern des Prozesses des Testens - Testen näher in den Fokus der Entwickler bringen - Verantwortung der Entwickler herausstellen - Permanentes Testen auf Komponentenebene - Testen einzelner Funktionen, Methoden, Klassen etc. in Isolation - Automatisieren des Testens - Testen auf Knopfdruck Folie 5
Test-Driven Development Auch Test-First Development genannt Iterativer Prozess Wird in andere Entwicklungsprozesse eingebettet - Extreme Programming, Scrumm, etc. Software wird auf atomarer Ebene getestet - Jede Funktion, Methode, Klasse, etc. wird getestet. - Daher sofortige Sichtbarkeit von funktionszerstörenden Änderungen. - Der Test Dokumentiert die Funktionalität der getesteten Komponenten. Folie 6
Test-Driven Development 1.ter Schritt: Test hinzufügen - Überlegen, was implementiert werden soll - Überlegen, wie es getestet werden soll - Den Test implementieren - Den Test ausführen - Fehlschlag beobachten Folie 7
Test-Driven Development 2.ter Schritt: Test erfüllen - Genug Code schreiben, um den Test laufen und fehlschlagen lassen zu können - Test ausführen, Fehlschlag beobachten - Code schreiben und den Test erfüllen - Test ausführen, den Erfolg beobachten Folie 8
Test-Driven Development 3.ter Schritt: Code vereinfachen, Refactoring - Redundanten Code entfernen - Ggf. Code Kommentieren - Code vereinfachen - Allgemeinheit des Codes erhöhen - Test laufen lassen, Erfolg beobachten Folie 9
Arten von Softwaretests Unit Test - Testet den einzelnen Baustein (Methode, Klasse) Integrationstest - Testet das Zusammenspiel der Bausteine Funktionaler Test - Testet die Anwendungsfälle (use cases) Folie 10
Arten von Softwaretests Stress Test - Testet das Systemverhalten unter hoher Last: Antwortzeiten, etc. Akzeptanztest - Testet die Software gegen die Anforderungen des Kunden Folie 11
Kritik Auch mit Test-Driven Development kann die Fehlerfreiheit der Software nicht garantiert werden. - Man weis, was getestet wurde, aber nicht, was übersehen wurde - Ein grüner Balken garantiert also nicht die Fehlerfreiheit der getesteten Komponente Wann ist die Codeabdeckung der Tests ausreichend? Der Wunsch grün zu testen, führt dazu, dass (unbewusst) nur soviel programmiert und getestet wird, dass der Test läuft. - Häufig in der Praxis beobachtetes Anti-Pattern Wenn Code- und Testautor die gleiche Person sind, können sich Denkfehler in der Implementation und im Test niederschlagen - Ergebniss: grüner Balken, obwohl Code und Test fehlerhaft sind Folie 12
Junit ist ein Framework zur Durchführung automatischer Blackbox- Tests in Java - Fokus auf Einfachheit, Automatismen, schnelle Feedback-Zyklen - Aktuelle Version: 4.10 (stand: 4.12.2011) - Open Source - Lizenz: Common Public License 1.0 - Homepage: http://www.junit.org - Entwickelt von Kent Beck, Erich Gamma, u.a. Folie 13
Integration in Eclipse - Seit Eclipse 3.0 als Plugin in der Default-Installation - Erstellen von Coderümpfen auf Knopfdruck - Testcases ohne Probleme - Testsuites über Umwege - File -> New -> Other -> Java -> Junit Test Case - Die Testmethoden müssen öffentlich und parameterlos sein, außerdem muss der Name mit test beginnen Folie 14
Folie 15
Folie 16
Klassendiagramm - TestCase-Objekt beinhaltet Tests Und definiert die Umgebung (Fixture) - TestSuite-Objekt beinhaltet und führt die verschiedenen TestCases aus - TestResult Objekte Sammeln die aufgetretenen Fehler - Assert beinhaltet statische Methoden für die Tests - TestRunner Führen die Tests aus, BaseTestRunner ust die Oberklasse Folie 17
Lebenszyklus der Tests - Before wird als erstes genau ein mal ausgeführt Schlüsselwort: @BeforeClass - Setup und Teardown werden jedes mal vor bzw. nach jedem Test ausgeführt Schlüsselwörter @Before, @After - After wird nach Beendigung aller Tests genau ein mal ausgeführt - Before, Setup, Teardown und After bilden zusammen die sog. Testfixture - Die Methoden für Before und After müssen als static deklariert werden Folie 18
Bsp.: Verkettete Liste - @BeforeClass: Erzeugung einer Neuen leeren Liste - @Before: Befüllen der Liste mit definierten Testdaten Folie 19
Bsp.: Verkettete Liste - @Test: der Test - @After: Löschen der Elemente In der Liste - @AfterClass: leere Methode Folie 20
Assertions - to assert (sth.): Etwas Behaupten, etwas feststellen - Assertion: eine Behauptung Folie 21
Assertions - asserttrue(boolean condition) behauptet, dass condition wahr ist. Folie 22
Assertions - assertfalse(boolean condition) behauptet, dass condition falsch ist. Folie 23
Assertions - assertequals(object a,object b) behauptet, a und b sein gleich - Für die Prüfung wird die Equals-Methode an a und b verwendet - Wenn a und b null sind, ist die Behauptung wahr Folie 24
Assertions - assertarrayequals(object[] a, Object[] b) behauptet, a und b sein gleich - Die Prüfung erfolgt Element für Element - Wenn a und b null sind, ist die Behauptung wahr Folie 25
Assertions - assertnotnull(java.lang.object a) behauptet, a ist kein Null-Pointer Folie 26
Assertions - assertnull(java.lang.object a) behauptet, a ist ein Null-Pointer Folie 27
Assertions - assertnotsame(object a, Object b) behauptet, die Referenzen auf a und b sind nicht identisch - Sinvoll, wenn assertequals() wahr ist Folie 28
Assertions - fail() und fail(string message) brechen einen Test ab. - Abbruch der Testmethode, Test schlägt fehl Folie 29
Arten von Fehlern - Junit unterscheidet zwei arten von Fehlern bei den Tests: - Failure: der Test schlug fehl. Eine AssertionErrorException wurde gefangen. Die getestete Methode/Klasse lieferte also einen unerwarteten Rückgabewert. - Error: Der Test konnte nicht ausgeführt werden. Der Fehler liegt i.d.r. in der Testklase Folie 30
Vielen Dank Fragen? Folie 31