Re-Engineering: Test-First-Ansatz. Dr. Thorsten Arendt Marburg, 17. Dezember 2015

Transkript

1 Re-Engineering: Test-First-Ansatz Dr. Thorsten Arendt Marburg, 17. Dezember 2015

2 Re-Engineering Patterns [Demeyer et al.] 2 Software-Evolution WS 2015/2016

3 Überblick Probleme Wie ändert man Teile eines Programms ohne Fehler in die bisherige Funktionalität einzubauen? Fehler in die neue Funktionalität einzubauen? Kosten für zukünftige Evolutionsschritte zu erhöhen? Teststrategien für sich ändernde Systeme Test-First-Ansatz: Tests für die Systemteile, die geändert werden sollen Tests für neue Systemteile 3 Software-Evolution WS 2015/2016

4 Welche Herausforderungen müssen betrachtet werden? Aus Sicht des Re-Engineerings Änderungen können neue Bugs einführen Es sind keine Tests vorhanden, auf die man zurückgreifen könnte Aus Sicht des Softwareentwicklungs-Prozesses Nicht alles kann getestet werden Unter Termindruck wird weniger getestet Aus Sicht der Kunden Kunden zahlen nicht für das Testen Instabile und/oder fehlerhafte Software ist inakzeptabel Aus Sicht der Entwickler Programmierer glauben, dass keine Tests benötigt werden Bug-Fixing macht keinen Spaß 4 Software-Evolution WS 2015/2016

5 Tests machen Evolution erst möglich Die Änderung eines bestehenden Systems ist risikoreich. Läuft der Code nach der Änderung? Welche Seiteneffekte hat eine Änderung? Probleme: Da das System nicht komplett verstanden wird, kann das Ausmaß einer Änderung nicht vorhergesagt werden. kann das System nach der Änderung labiler werden. Lösung: Verwendung von Testsuiten Automatisierte Testfälle Probleme 5 Software-Evolution WS 2015/2016

6 Eigenschaften von Testsuiten Alle Tests sind automatisiert und können gespeichert werden. Alle Tests können wiederholt werden. Es werden Einheiten (Methoden, Klassen, Pakete) getestet. Es gibt möglichst wenig Abhängigkeiten zwischen den Tests. Die Tests sind immer passend zum zu testenden System. Die Tests sollten Grey-Box-Tests sein. 6 Software-Evolution WS 2015/2016

7 Vor- und Nachteile dieser Technik (Verwendung von Testsuiten) Vorteile Nachteile Tests erhöhen das Vertrauen in das System Zusätzliche Dokumentation der Funktionalität Test-Frameworks für einfache Unit-Tests vorhanden Zusätzlicher Aufwand Tests demonstrieren lediglich vorhandene Fehler Ungeeignete Tests führen zu falschem Vertrauen in das System Fehler können früh gefunden werden 7 Software-Evolution WS 2015/2016

8 Testmanagement Probleme: Vorhandene Funktionalität ist möglicherweise komplex und unzureichend dokumentiert und getestet Während der Umsetzung einer Evolutionsaufgabe sind Ressourcen für das Schreiben von Tests begrenzt Wann testen? Wann aufhören zu testen? Lösung: Probleme Inkrementelles Einführen von Tests für diejenigen Systemteile, an denen gearbeitet wird 8 Software-Evolution WS 2015/2016

9 Welche Systemteile sollen getestet werden? Teile, die wir nicht komplett verstehen, aber für das Re-Engineering benötigen Teile, die wir zwar komplett verstehen und benötigen, aber die Fehler enthalten Fragile Teile, also Teile, deren Funktionalität zwar verstanden ist, aber nicht ihre Implementierung Neue Systemteile Schnittstellen, nicht ihre Implementierungen 9 Software-Evolution WS 2015/2016

10 Beispiel: Welche Systemteile sollen getestet werden? [Demeyer et al.] Nicht nur Komponente B sondern auch Komponente ABC. Integrationstests 10 Software-Evolution WS 2015/2016

11 Vor- und Nachteile dieser Technik (Inkrementelle Erweiterung der Testbasis) Vorteile Nachteile Zeitersparnis durch Konzentration auf wesentliche Systemteile Vertrauensaufbau durch Testfallerweiterung Investition in die Zukunft Start der Umsetzung der Evolutionsaufgabe bevor sämtliche Tests vorhanden sind Unwissen, welche Teile wirklich kritisch sind Falsches Vertrauen durch zusätzliche versteckte Fehler Wo sind die Grenzen der zu testenden Komponenten? 11 Software-Evolution WS 2015/2016

12 Testorganisation Probleme: Das Schreiben von Tests kann langweilig sein und das Aufsetzen umfangreicher Testdaten notwendig machen Es ist unter Umständen schwierig, zwischen fehlgeschlagenen Tests und unerwarteten Fehlern zu unterscheiden Womit kann systematisch getestet werden? Lösung: Probleme Verwendung eines Test-Frameworks, mit dem man Testsuiten aus einzelnen Testfällen erstellen kann 12 Software-Evolution WS 2015/2016

13 Das Test-Framework JUnit JUnit unterstützt automatisiertes Testen, d.h. es verlangt während der Tests keine Benutzerinteraktion. Wesentliche Prinzipien: Zu jeder verfassten Klasse wird eine Testklasse entworfen. Testcode und Anwendungscode sind strikt getrennt. Testcode wird in Testfälle strukturiert. Ein Testfall kann mit SetUp und TearDown-Methoden vorbereitet bzw. abgeschlossen werden. Ein Testfall hat drei Teile: Datenvorbereitung Aufruf der zu testenden Methode Testbedingung (Assertion) 13 Software-Evolution WS 2015/2016

14 JUnit Beispiel: Programmcode 1 14 Software-Evolution WS 2015/2016

15 JUnit Beispiel: Programmcode 2 15 Software-Evolution WS 2015/2016

16 JUnit Beispiel: Testfallklasse 16 Software-Evolution WS 2015/2016

17 JUnit Beispiel: Fehlgeschlagener Test 17 Software-Evolution WS 2015/2016

18 Vor- und Nachteile dieser Technik (Verwendung von Testframeworks) Vorteile Nachteile Vereinfacht die Formulierung von Tests Animiert Programmierer, Tests in ihrer gewohnten Welt zu schreiben und durchzuführen Hierarchische Organisation der Tests ermöglicht Konzentration auf wesentliche Systemteile Benötigt Disziplin, (Selbst-) Verantwortung und Pflege 18 Software-Evolution WS 2015/2016

19 Wie testen? Wiederverwendbare Tests Probleme: Das System ändert sich, aber die meisten Features des Systems sollen weiterhin funktionieren. Tests sollen möglichst unabhängig von Reengineering- Schritten sein, um den Testaufwand gering zu halten. Lösung: Probleme Schnittstellen beschreiben, was ein System tut und tendieren dazu, stabiler als ihre Implementierungen zu sein. Blackbox-Tests, die Schnittstellen testen 19 Software-Evolution WS 2015/2016

20 Identifikation von repräsentativen Testfällen (Daten-getrieben) Zum datengetriebenen Testen einer funktionalen Einheit (z.b. Methode) hat sich das folgende Verfahren aus [OB88] bewährt: 1. Erstelle ein Modell der Eingabedatenstrukturen Welche Datenkategorien gibt es für die Parameter? Welche Objekte der Umgebung müssen berücksichtigt werden? 2. Zerlege den Datenraum jeder Kategorie in Wahlmöglichkeiten Wie viele Kombinationen von Wahlmöglichkeiten gibt es? 3. Welche Kombinationen sind möglich? Welche Abhängigkeiten gibt es zwischen den identifizierten Wahlmöglichkeiten? 4. Für jede mögliche Kombination von Wahlmöglichkeiten werden passende Werte gewählt und ein Testfall geschrieben. Dieser enthält auch den Erwartungswert. 20 Software-Evolution WS 2015/2016

21 Vor- und Nachteile dieser Technik (Testen von Schnittstellen) Vorteile Nachteile Schnittstellentests sind besser wiederverwendbar Blackbox-Tests können für verschiedene Implementierungen benutzt werden Blackbox-Tests decken nicht unbedingt alle Pfade ab Testanpassung bei Schnittstellenänderungen Schnittstellen sind einfacher zu testen 21 Software-Evolution WS 2015/2016

22 Wie testen? Geschäftsregeln als Tests Die meisten Geschäftsregeln sind wohldefiniert und durch Beispiele illustriert. Aufbau einer Geschäftsregel: WENN DANN SONST Was tun mit implizit im Code vorhandenen Geschäftsregeln? Nicht extrahieren Entwickler und Nutzer fragen 22 Software-Evolution WS 2015/2016

23 Vor- und Nachteile dieser Technik (Geschäftsregeln als Tests) Vorteile Nachteile Regeln werden explizit Dokumentation der Geschäftsregeln Nur Szenarios, keine Logik Schwierig bei großer Anzahl von Geschäftsregeln 23 Software-Evolution WS 2015/2016

24 Wann testen? Tests für besseres Verstehen Wie versteht man einen Systemteil, für den es weder Tests noch genügend Dokumentation gibt? Kodierung der Hypothesen in ausführbare Tests. Blackbox-Tests: Verständnis der Rollen und Kollaborationen Whitebox-Tests: Verständnis des internen Algorithmus Präzise Benutzung der Objekte erforderlich Probleme: Erzeugung der nötigen Objekte ist schwierig. Codestellen, an denen diese Objekte erzeugt werden, können helfen. Nebenläufige Systeme sind schwer zu testen. 24 Software-Evolution WS 2015/2016

25 Vor- und Nachteile dieser Technik (Tests für besseres Verstehen) Vorteile Nachteile Verständnis der Strukturen kann überprüft werden Kostet zusätzliche Zeit Tests sind nicht fuzzy, sondern präzise Tests können zum Verstehen des Codes auf unterschiedlichen Ebenen verwendet werden 25 Software-Evolution WS 2015/2016

26 Wann testen? Tests für neue Funktionalitäten Verwende Test-First-Ansatz: Erst die Tests, dann die Implementierung der neuen Funktionalität Grundlage: Modell des geänderten Systems Blackbox-Tests für die neuen Teile (Methoden, Anwendungsfälle) Probleme: Modell ist zu grob: Wesentliche Funktionalität versteckt. Modell unvollständig: Wesentliche Funktionalität fehlt. Lösung: Iteratives Modellieren: eventuelles Modell-Refactoring, kann Auswirkungen auf die Tests haben Anwendungsfälle testen Regressionstests nach jeder Änderung 26 Software-Evolution WS 2015/2016

27 Einsatz von Daten-getriebenen Tests in der Test-getriebenen Entwicklung Vorgehensweise: Beschreibe wesentliche Testfälle schon mit den Anforderungen Folge dem vorgestellten Verfahren zur Identifikation von repräsentativen Testfällen Programmiere alle repräsentativen Testfälle Führe die Testfälle aus: Fehler, da die Funktionalität noch fehlt Implementiere die Funktionalität Führe die Testfälle aus: Code solange ändern, bis alle Tests durchlaufen Führe Refactorings durch 27 Software-Evolution WS 2015/2016

28 Vor- und Nachteile dieser Technik (Tests für neue Funktionalitäten) Vorteile Nachteile Anforderungen in Tests gegossen Bei Designanpassungen sind auch Testanpassungen nötig Nicht am Kunden vorbei entwickelt 28 Software-Evolution WS 2015/2016

29 Zusammenhang von Test-Patterns [Demeyer et al.] 29 Software-Evolution WS 2015/2016

30 Zusammenfassung Testen zum besseren Verständnis und als Voraussetzung für sicheres Re-Engineering Sowohl die neue als auch die zu ändernde Funktionalität soll durch Tests abgesichert sein. Vorwiegend Blackbox-Tests Schnittstellen statt Implementierung testen Die Tests sollten sich auf die geänderten Methoden und größere Einheiten beziehen. Test-First-Ansatz: Erst die Tests, dann die Implementierung der neuen Funktionalität. 30 Software-Evolution WS 2015/2016

31 Quellen und Werkzeuge Literatur: Serge Demeyer, Stephane Ducasse, Oscar Nierstrasz: Object-Oriented Reengineering Patterns, 2013, Kap. 6, online verfügbar unter Ostrand, Thomas J., and Marc J. Balcer: The categorypartition method for specifying and generating functional tests, Communications of the ACM 31.6 (1988): Werkzeuge: JUnit: 31 Software-Evolution WS 2015/2016