Lohnt sich testbasierte Software-Entwicklung iX Konferenz 2005: Bessere Software Prof. Peter Sommerlad IFS Institut für Software HSR Hochschule für Technik Rapperswil Oberseestrasse 10, CH-8640 Rapperswil Bessere Software – Einfach, Schneller

IFS: Bessere Software - Einfach, Schneller 2 Peter Sommerlad Arbeitsgebiete oModernes Software Engineering oPatterns Pattern-oriented Software Architecture (POSA) Security Patterns oProgrammieren oTest-Infiziert seit 1998 Background oDiplom-Informatiker (Univ. Frankfurt/M) oSiemens Corporate Research - München oitopia corporate information technology, Zürich (Partner) oProfessor für Informatik HSR Rapperswil, Leiter IFS Credo: Menschen machen Software oKommunikation oFeedback oMut Erfahrung durch Praxis oProgrammieren ist Handwerk oPatterns aus der Praxis kapseln Erfahrung Pragmatisches Programmieren oTest-Driven Development oEntwicklungsautomation oEinfachheit: Kampf gegen Komplexität

IFS: Bessere Software - Einfach, Schneller 3 Agenda Was ist testbasierte Entwicklung? oPragmatische Praktiken Fallbeispiel aus der Industrie oC++ Framework für Web Applikationen oHistorische Betrachtung Vorteile und Risiken testbasierter Entwicklung oEntwickler, Kunden, Anbieter Zusammenfassung, Ausblick, Appell

IFS: Bessere Software - Einfach, Schneller 4 Was ist testbasierte Entwicklung? Automatisierte Tests stellen die Software Qualität sicher Unit Testing oFür jede Komponente/Klasse/Methode, die eine nicht-triviale Implementerung hat, werden eine oder mehrere Testmethoden implementiert. oDie Tests sollten isoliert ablaufen. Benötigte Umfeld-Objekte werden mittels sog. mock-objects simuliert, um Abhängigkeiten zu vermeiden. oOft werden Tests für Grenzfälle und das Normalverhalten erstellt. oÜberprüfen der technischen Qualität der Implementierung. Functional Testing oRelevantes externes Verhalten wird auf Systemebene getestet. oTestbarkeit durch Isolation von Teilsystemen mittels mock-objects verbesserbar. oÜberprüfen der fachlichen Qualität. Idealerweise: Test-First oZuerst Test und Schnittstelle realisieren, dann implementieren.

IFS: Bessere Software - Einfach, Schneller 5 Unit Tests Test eines Moduls (Übersetzungseinheit, = Quell-Datei) ooder kleinere Einheit... Test durch Programmierer selbst automatisch, wiederholbar vorausgesetzte Ergebnisse - Assertions Unit Testing Frameworks: JUnit, NUnit (C#), CppUnit(C++), etc. owww.junit.org ohttp://

IFS: Bessere Software - Einfach, Schneller 6 JUnit Beispiel Zu testende Klasse JUnit Testcode (ein paar Testfälle) heute in Eclipse (JUnit) oder Visual Studio (NUnit) eingebaut

IFS: Bessere Software - Einfach, Schneller 7 JUnit Aufbau import junit.framework.*; public class EuroTest extends TestCase { public void testAmount() { Euro two = new Euro(2.00); assertTrue(two.getAmount() == 2.0); } public static void main(String[] args) { junit.swingui.TestRunner.run(EuroTest.class); } (plus die zu testende Klasse "Euro")

IFS: Bessere Software - Einfach, Schneller 8 Pragmatische Prinzipien beim Unit Testing Test anything that might break okeine Tests für "funktionslosen" Code Test everything that does break obei Fehler zuerst einen Test schreiben, der den Fehler reproduziert, dann korrigieren New code is guilty until proven innocent Write at least as much test code as production code Run local tests with each compile onicht weitermachen bevor Tests 100% laufen Run all tests before check-in to repository

IFS: Bessere Software - Einfach, Schneller 9 Was wie Testen? Use your Right-BICEP Are the results right? oassertEquals(42,7*6) Are all boundary conditions CORRECT? o0, 1, 0xfffffff Can you check inverse relationships? osqrt(x)*sqrt(x) == x Can you cross-check results using other means? Can you force error conditions to happen? oy/x, x=0 Are performance characteristics within bounds? osiehe JUnitPerf (

IFS: Bessere Software - Einfach, Schneller 10 CORRECT Boundary Conditions Conformance oz.B. Adresse prüfen: Ordering oIst Reihenfolge relevant? Was passiert wenn falsch? Range oStimmt der Wertebereich der Ergebnisse Reference oAnnahmen über Umfeld prüfen Existence oIst etwas da? Nicht null/nil? Cardinality ooff-by one errors, 0,1,viele Time oReihenfolge in der etwas passiert, Concurrency

IFS: Bessere Software - Einfach, Schneller 11 Projektautomation kurzer Überblick Prinzip: Eine IDE ersetzt nicht die Automation! Build beinhaltet immer alle automatischen Tests onur OK, wenn Tests 100% Ok Alle Tätigkeiten, die im Projekt mehr als einmal (manuell) ausgeführt werden (müssen), sind automatisiert!

IFS: Bessere Software - Einfach, Schneller 12 Automation Road Map Quelle: Pragmatic Project Automation Versionsmanagement ist selbstverständlich, oder? ocvs, svn, etc. oalles, das nicht automatisch generiert werden kann, liegt im Repository! Build Prozess auf separatem Build Server setzt auf das Repository auf (next slide)

IFS: Bessere Software - Einfach, Schneller 13 Automatisierung mit Build-Server So soll es sein! OOPS, File vergessen einzuchecken

Fallbeispiel aus der Praxis Grosses hochperformantes Framework für Web-Applikationen mit mehreren Kunden und Produktivsystemen aus den 90ern

IFS: Bessere Software - Einfach, Schneller 15 Geschichtsbetrachtung 1997 Web Application Framework in C++ oInternet Banking Schweizer Grossbank oOnline Game mit ca usern oFinanzinformationsportal mit 5 – gleichzeitig aktiven professionellen usern noch heute im Einsatz und aktiv weiterentwickelt 1997 – keine automatischen Unit Tests ojeder Entwickler/Applikation hat eigene Version oKorrektur von Kernabstraktionen und Infrastruktur notwendig, aber zu riskant oRefactoring-Stau

IFS: Bessere Software - Einfach, Schneller 16 Ursachen 1997 Furcht vor Änderungen am Framework oRisiko: Destabilisierung existierenden Codes oRisiko: Change Propagation in fertige Applikationen oRisiko: Mehraufwand für wiederholtes Testen oRisiken sind schwer einzuschätzen Qualitätsmängel im Framework oFIXME Kommentare: quick hacks, trial and error oVerwendung von C-legacy considered harmful: sscanf, vprintf, char * oTeilweise unsauberes Verhalten im Multi-threaded Fall oTeilweise unsauberes Memory Management Änderungen erfordern zu viel Mut und Angstschweiss, dass etwas kaputt geht

IFS: Bessere Software - Einfach, Schneller 17 Vision : Demo von Test-first Programming von Kent Beck und Erich Gamma Das müssten wir auch machen! Wenn das Framework mit automatischen Tests abgestützt wäre, dann sollten Änderungen am Framework ohne Probleme machbar sein. Technische Varianten könnten gegeneinander abgewägt werden. Technische Verbesserungen könnten idealerweise ohne Implikation auf Applikationen erfolgen. Impakt-Abschätzung von (Schnittstellen-) Änderungen wäre möglich. Daily Build mit automatischen Tests verbinden.

IFS: Bessere Software - Einfach, Schneller 18 Was hat es gebracht? (1) 2000 Stabilität oGrenzfälle besser abgedeckt z.b. 0, 1, viele, ganz viele, negativ ? Refactoring im Framework wurde möglich oz.B. Reduktion von unnötigem Locking, optimiertes Memory Mgmt Portabilität auf andere Plattformen abgesichert oAIX, Windows NT, Teilbereiche auf exotisches IBM Host OS (TPF) Nachträgliche Implementierung von Tests teilweise aufwändig oerste Tests teilweise zu umfangreich

IFS: Bessere Software - Einfach, Schneller 19 Was hat es gebracht? (2) 2000 Austauschbarkeit von (ungünstigen) Implementierungen oElimination von C-Legacy und FIXMEs Besseres Interface Design von neuen Dingen oTest-first und Testability sind gute Ratgeber fürs Schnittstellendesign Einfachere Flexibilisierung Vertrauen in fremden Code bei Entwicklern gestiegen oKonsolidierung von Code oreduziertes Risiko, bzw. Risiko einschätzbar, indem man Testcase schreibt, bevor man Änderung macht

Vorteile und Risiken testbasierter Entwicklung anhand eigener Erfahrungen

IFS: Bessere Software - Einfach, Schneller 21 Vorteile testbasierter Entwicklung (Entwickler) Qualität des Codes gesteigert obei guten Testfällen, Grenzfälle abdecken sicheres Refactoring wird ermöglicht okein Domino-Effekt bei Änderungen gut testbarer Code hat besseres, einfacheres Design ohohe Kohäsion, niedrigere Kopplung Testcode macht Entwickler zum "Opfer" seines Schnittstellendesigns obessere und einfacher nutzbare Interfaces Testcode dokumentiert Anforderungen oTest-First macht das explizit: zuerst die Anforderung als Test kodieren Debugger wird verzichtbar oBug wird im Testcase manifestiert, tritt nie wieder auf

IFS: Bessere Software - Einfach, Schneller 22 Schwierigkeiten für Entwickler Zeit, Coaching und Erfahrung nötig für gute Tests oSupport durch Kollegen und Führung! Tests sind auch Code obrauchen Refactoring unnötige Tests behindern oPlattformtests, "false positives" behindern ozu viele "Normalfälle" getestet Tests müssen rasch ablaufen oso oft wie möglich ausführen Tests müssen isoliert sein okeine Abhängigkeiten von anderen Tests und Infrastruktur Mock-Objekts einsetzen Tests für existierenden Code schreiben ist schwerer ooft zu viele Abhängigkeiten im Code -> schlechtes Design aber essentiell für Refactoring von "Altcode" schlechte Tests sind Hinweis auf schlechtes Design Heute gibt es gute Literatur zum Thema.

IFS: Bessere Software - Einfach, Schneller 23 Vorteile für Kunden Qualität der Lösung ist besser ooft schnellere, kostengünstigere Ergebnisse okeine lange Test- und Integrationsphase notwendig Änderungswünsche können ohne Qualitätsrisiko rasch umgesetzt werden oinkrementelle Entwicklung ist einfacher Wartung und Weiterentwicklung günstiger oFehler treten nur einmal auf oFehler werden durch Tests erkannt und nicht erst durch Anwender Lebensdauer der Software ist länger

IFS: Bessere Software - Einfach, Schneller 24 Risiken für Kunden Auf den ersten Blick sieht testbasierte Entwicklung teurer aus omehr Code zu schreiben oRefactoring bedeutet funktionierenden Code zu ändern Qualtiät kann "zu gut" sein ointerne QA Abteilung "überflüssig" o"Reifezeit" in QA/Systemintegration unnötig rasches häufiges Deployment nicht üblich Einfachheit von Änderungen kann zu Oszillation in den Anforderungen führen oinnere Konflikte kommen heraus

IFS: Bessere Software - Einfach, Schneller 25 Vorteile für Anbieter Hohe Qualität führt zu anerkannten Lösungen oKundenzufriedenheit Zufriedene Entwickler oweniger Stress durch Sicherheitsnetz aus Tests Leichtere Einarbeitung neuen Personals oTests verhindern "kaputtmachen" innere Qualtität des Codes kann verbessert werden oZukunftssicherung Portierbarkeit auf andere Plattformen

IFS: Bessere Software - Einfach, Schneller 26 Risiken für Anbieter Qualität geschätzt aber Preis nicht gezahlt oKunde erkennt Agilität und nutzt Anbieter aus zufriedene Kunden kündigen Support & Wartungsverträge ozu gute Qualität rächt sich ospeziell bei Quellcodelieferung inkl. Testcases Schlechtere Softwarequalität führt zu mehr Kundenkontakten obessere Kundenbindung, Projektpotential Neue Kunden sind schwer von Vorteilen zu überzeugen oQualtiätsniveau ist (noch) nicht marktüblich

IFS: Bessere Software - Einfach, Schneller 27 Zusammenfassung, Ausblick Ich bin "test-infiziert" obereue jede eigene Entwicklung ohne Tests ofordere konsequent von Studenten und Mitarbeitern automatisierte Tests okenne Chancen aber auch mögliche Risiken und Gegenmassnahmen Testbasierter Entwicklung gehört die Zukunft oEclipse macht es vielen vor auch wenn es selbst nur relativ wenige Testcases hat oBestandteil unserer Ausbildung an der HSR ogute Applikationstest tw. noch schwierig

IFS: Bessere Software - Einfach, Schneller 28 Appell Lernen Sie, selbst testbasiert zu entwickeln ounterstützen Sie Ihre Entwickler dabei oPraxis ist notwendig oLiteratur unterstützt Erlauben Sie ihren Entwicklern testbasierte Entwicklung zu erlernen obeachten Sie die Lernkurve zum Erfahrungsaufbau, es braucht Zeit oAusbildung, Übung, Literatur oeinfach Anfangen, nicht Abwarten Fragen?

IFS: Bessere Software - Einfach, Schneller 29 Literatur Andy Hunt, Dave Thomas, Mike Clark: Pragmatic Starter Kit: oPragmatic Unit Testing with JUnit/NUnit J.B. Rainsberger: JUnit Recipes Kent Beck: Test-driven Development by Example Dave Astels: Test-driven Development Lisa Crispin, Tip House: Testing Extreme Programming Johannes Link: Unit Tests mit Java Werbung :-) Pattern-oriented Software Architecture: A System of Patterns (Buschmann,Meunier,Rohnert,Sommerlad,Stal) Security Patterns (2005, M. Schumacher et al) Fragen zu Patterns, etc.: