HUMBOLDT-UNIVERSITÄT ZU BERLIN MENSCH-TECHNIK-INTERAKTION ARBEITSGRUPPE SOFTWARETECHNIK (INSTITUT FÜR INFORMATIK) ARBEITSGRUPPE INGENEURPSYCHOLOGIE (INSTITUT FÜR PSYCHOLOGIE) Unit Testing, SUnit & You M. Hildebrandt N. Niestroj
Agenda» Unit Testing» Begriffsklärung» Eigenschaften» Test-driven Development» SUnit» Geschichte» Framework» Testschritte 2
Begriff: Testen» Vorgehen» Anwenden des Testlings auf definierte Eingabewerte» Vergleich der Ergebnisse mit Erwartungswerten» Ziel» Finden von Fehlern» Nicht: Nachweis von Korrektheit Absence of proof is NOT proof of absence. 3
SUnit im Entwicklungsprozess Anwendungsszenarien Abnahmetest Grobentwurf Testfälle Systemtest Feinentwurf Testfälle Integrationstest Anforderungsdefinition Modulimplementation Testfälle Modultest 4
Unit Test vs. Integrationstest» Unit Test» Test, welcher sich auf Komponenten eines Systems bezieht» Methode, Klasse, Subsystem, Gesamtsystem» meistens: Klasse (CUT) bzw. Objekt (OUT) oder Software (SUT)» verwendet Testing Framework» Integrationstest» Test, welcher sich auf das Zusammenspiel mehrerer Komponenten bezieht» Komponenten bereits einzeln getestet» Abgrenzung nicht immer einfach» z.b. wenn die Integration mit Klassen implementiert ist 5
Unit Test vs. Integrationstest (con)» Stub:» Platzhalter für geplante aber noch nicht implementierte Funktionalität» Dummy:» Ersatz für die echte Implementierung für Testzwecke» simuliert die echte Implementierung, meist stark reduziert» Mock:» Dummy, welcher zusätzlich Testcode enthält» Benutzt für endoskopisches Testen 6
Unit Test: Eigenschaften» wiederholt und automatisiert ausführbar» häufiges Wiederholen möglich» der Test läuft schnell durch» häufiges Wiederholen möglich» ist unabhängig von anderen Tests» kann immer wieder unter denselben Bedingungen ausgeführt werden» einfach zu implementieren» kompliziertes Setup weißt auf Integrationstests hin Osherove, Roy (2007). The Art Of Unit Testing Manning Publications 7
Unit Test: Eigenschaften (con)» dienen der Beschreibung von Funktionalität» demonstrieren Benutzung und erwartetes Verhalten» sollte nicht öfter geändert werden als der getestete Code» auch für andere Entwickler zugänglich Osherove, Roy (2007). The Art Of Unit Testing Manning Publications 8
Was ist kein (guter) Unit Test?» Tests, die nach einen Tag/Monat/Jahr nicht mehr gültig sind» Tests, die nur vom Verfasser ausgeführt und interpretiert werden können» Tests, die länger als wenige Minuten zur Ausführung brauchen» Testsammlungen, die nicht durch einen Buttondruck ausgeführt werden können» Tests, die mehr als wenige Minuten zur vollständigen Implementierung brauchen Osherove, Roy (2007). The Art Of Unit Testing Manning Publications 9
Agenda» Unit Testing» Begriffsklärung» Eigenschaften» Test-driven Development» SUnit» Geschichte» Framework» Testschritte 10
Test-driven Development» agile Methode zur Entwicklung von Software» flexibler und schlanker Entwicklungsprozess» Reduzierung der Entwurfsphase auf ein Minimum» inkrementelle und iterative Entwicklung» Ziel: so früh wie möglich ausführbare Software» gemeinsame Abstimmung mit den Kunden» regelmäßig und in kurzen Abständen» Vorteil: flexibles Eingehen auf Kundenwünsche» Wünsche ändern sich (häufig)» Kunden wissen oft nicht so genau, was sie denn wollen» Kommunikationsprobleme 11
Test-driven Development (con)» Problem: häufige Änderungen am Code» erhöhte Fehlerwahrscheinlichkeit» Also: häufiges Testen» erfordert einfache und schnelle Tests» erfordert testbare Implementierung» also» Vorgehen: 1. Entwicklung von Tests 2. Entwicklung von Produktivcode» dabei: nur getestete Funktionalität implementieren» nichts unter Voraussicht künftiger Funktionalität» falls Anpassung nötig: Refactoring 12
Test-driven Development: Coding Phase» Bisheriger Ansatz: 13
Test-driven Development: Coding Phase (con)» Test-First Ansatz: 14
Agenda» Unit Testing» Begriffsklärung» Eigenschaften» Test-driven Development» SUnit» Geschichte» Framework» Testschritte 15
SUnit im Entwicklungsprozess Anforderungsdefinition Anwendungsszenarien Abnahmetest Grobentwurf Testfälle Systemtest Feinentwurf Testfälle Integrationstest Modulimplementation Testfälle Modultest SUnit 16
SUnit» Testing Framework für Smalltalk» Kent Back:» Simple Smalltalk Testing With Patterns (1989)» (ursprünglicher) Entwickler von Sunit» Schöpfer vom extrem Programming 17
SUnit Framework Black, A.P., Ducasse, P., Nierstrasz, O., Pollet, D. (2008). Squeak By Example 18
SUnit Framework: TestCase» abstrakte Klasse, wird für eigene Tests abgeleitet» Gruppe von Tests mit gemeinsamen Kontext» Tests: Methoden» Kontext: Instanzvariablen» Testdurchlauf» erzeuge neue TestCase Instanz» führe setup aus (erzeuge Kontext)» führe Testmethode aus» führe teardown aus (aufräumen)» Testdurchlauf wird für jede Methode ausgeführt 19
SUnit Framework (cont): TestSuite» gruppiert TestCases und TestSuites» ebenfalls ausführbar» sinnvoll bei zwei und mehr Testfällen, die automatisiert hintereinander ausgeführt werden sollen 20
SUnit Framework (cont): TestResult» Ergebnis einer TestSuite-Ausführung» beinhaltet» Anzahl bestandener Tests» Anzahl nicht bestandener Tests (failures)» Anzahl an aufgetretene Fehler (errors)» Anzahl ausgeführter Tests 21
SUnit Framework: TestResource» Singleton» sinnvoll, wenn eine Ressource» aufwendig zu initialisieren ist» von mehreren Testfällen (einer TestSuite) benutzt wird» es genügt die Ressource nur einmal für eine Testsuite zu initialisieren» Testfälle, die Ressource nicht zerstören können» muss mit einer TestCase Instanz assoziiert werden» Beispiel: Datenbankverbindung 22
Agenda» Unit Testing» Begriffsklärung» Eigenschaften» Test-driven Development» SUnit» Geschichte» Framework» Testschritte 23
SUnit: Testschritte im Überblick 1. Erstellen einer Testklasse 2. Kontext des Testes erschaffen 3. Testmethoden schreiben 4. Tests laufen lassen 5. Ergebnisse interpretieren 24
Schritt 1: Testklasse erstellen» dazu wird immer von TestCase eine Unterklasse erstellt» Beispiel: ATEOOperateurTest» gruppiert Tests für die Klasse ATEOOperateur 25
Schritt 2: Testkontext erstellen» Testkontext:» Instanzvariablen» Methode setup» für jeden Durchlauf neu erzeugt» Beispiel: ATEOOperateurTest>>setUp 26
Schritt 3: Testmethoden schreiben» jede Methode ist ein Test» Name muss mit test beginnen» keine Parameter» Hilfsmethoden» assert: abooleanorblock» abooleanorblock enthält den eigentlichen Test oder auszuwertenden Ausdruck» evaluiert zu true oder false» abooleanorblock = true Test bestanden abooleanorblock = false Test nicht bestanden» deny: abooleanorblock» Negation von assert: assert: abooleanorblock value not 27
Schritt 3: Testmethoden schreiben (con)» Hilfsmethoden» should: ablock raise: anexceptionalevent» ablock enthält Testcode und soll die Ausnahme anexceptionalevent auslösen» Ausnahme tritt auf Test bestanden» Ausnahme tritt nicht auf Test nicht bestanden» shouldnt:raise:» Negation von should 28
Schritt 3: Testmethoden schreiben (con)» Beispiel: ATEOOperateurTest>>testPopupDown 29
Schritt 4: Test laufen lassen» Testrunner in Squeak 30
Schritt 5: Ergebnisse interpretieren» Mögliche Ausgänge eines Tests 1. Test bestanden z.b. Block bei assert wertet zu true aus 2. Test nicht bestanden (failure) z.b. Block bei assert wertet zu false aus 3. Test abgebrochen wegen einem Fehler (error) z.b. MessageNotUnderstood, IndexOutOfBounds 31
Schritt 5: Ergebnisse interpretieren (cont.) 32
DANKE FÜR DIE AUFMERKSAMKEIT. Fragen? Hinweise? Ergänzungen? 33