Lohnt sich testbasierte Software-Entwicklung iX Konferenz 2005: Bessere Software

Lohnt sich testbasierte Software-EntwicklungiX Konferenz 2005: Bessere SoftwareProf. Peter SommerladIFS Institut für SoftwareHSR Hochschule für Technik RapperswilOberseestrasse 10, CH-8640 Rapperswilwww.ifsoftware.ch

Bessere Software – Einfach, Schneller

IFS: Bessere Software - Einfach, Schneller 2

Peter [email protected]• Arbeitsgebiete

o Modernes Software Engineering

o Patterns Pattern-oriented Software

Architecture (POSA) Security Patterns

o Programmiereno Test-Infiziert seit 1998

• Backgroundo Diplom-Informatiker (Univ.

Frankfurt/M)o Siemens Corporate Research

- Müncheno itopia corporate information

technology, Zürich (Partner)o Professor für Informatik HSR

Rapperswil, Leiter IFS

Credo:

• Menschen machen Softwareo Kommunikationo Feedbacko Mut

• Erfahrung durch Praxiso Programmieren ist Handwerko Patterns aus der Praxis

kapseln Erfahrung• Pragmatisches

Programmiereno Test-Driven Developmento Entwicklungsautomationo Einfachheit: Kampf gegen

Komplexität


Agenda

•Was ist testbasierte Entwicklung?o Pragmatische Praktiken

•Fallbeispiel aus der Industrieo C++ Framework für Web Applikationeno Historische Betrachtung

•Vorteile und Risiken testbasierter Entwicklungo Entwickler, Kunden, Anbieter

•Zusammenfassung, Ausblick, Appell


Was ist testbasierte Entwicklung?Automatisierte Tests stellen die Software Qualität sicher• Unit Testing

o Für jede Komponente/Klasse/Methode, die eine nicht-triviale Implementerung hat, werden eine oder mehrere Testmethoden implementiert.

o Die Tests sollten isoliert ablaufen. Benötigte Umfeld-Objekte werden mittels sog. „mock-objects“ simuliert, um Abhängigkeiten zu vermeiden.

o Oft werden Tests für Grenzfälle und das Normalverhalten erstellt.o Überprüfen der technischen Qualität der Implementierung.

• Functional Testingo Relevantes externes Verhalten wird auf Systemebene getestet.o Testbarkeit durch Isolation von Teilsystemen mittels mock-objects

verbesserbar.o Überprüfen der fachlichen Qualität.

• Idealerweise: Test-Firsto Zuerst Test und Schnittstelle realisieren, dann implementieren.


Unit Tests

•Test eines Moduls (Übersetzungseinheit, = Quell-Datei)o oder kleinere Einheit...

•Test durch Programmierer selbst•automatisch, wiederholbar•vorausgesetzte Ergebnisse - Assertions

Unit Testing Frameworks: •JUnit, NUnit (C#), CppUnit(C++), etc.

o www.junit.orgo http://www.xprogramming.com/software.htm


JUnit Beispiel

•Zu testende Klasse•JUnit Testcode (ein paar Testfälle)

heute in Eclipse (JUnit) oder Visual Studio (NUnit) eingebaut


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")


Pragmatische Prinzipien beim Unit Testing

•Test anything that might breako keine Tests für "funktionslosen" Code

•Test everything that does breako bei 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

o nicht weitermachen bevor Tests 100% laufen•Run all tests before check-in to repository


Was wie Testen?Use your Right-BICEP•Are the results right?

o assertEquals(42,7*6)•Are all boundary conditions CORRECT?

o 0, 1, 0xfffffff•Can you check inverse relationships?

o sqrt(x)*sqrt(x) == x•Can you cross-check results using other means?•Can you force error conditions to happen?

o y/x, x=0•Are performance characteristics within bounds?

o siehe JUnitPerf (www.clarkware.com)


CORRECT Boundary Conditions•Conformance

o z.B. email Adresse prüfen: [email protected]•Ordering

o Ist Reihenfolge relevant? Was passiert wenn falsch?•Range

o Stimmt der Wertebereich der Ergebnisse•Reference

o Annahmen über Umfeld prüfen•Existence

o Ist etwas da? Nicht null/nil?•Cardinality

o off-by one errors, 0,1,viele•Time

o Reihenfolge in der etwas passiert, Concurrency


Projektautomationkurzer Überblick

•Prinzip:

•Eine IDE ersetzt nicht die Automation!

•Build beinhaltet immer alle automatischen Testso nur OK, wenn Tests 100% Ok

Alle Tätigkeiten, die im Projekt mehr als einmal (manuell) ausgeführt werden (müssen), sind automatisiert!


Automation Road Map

•Quelle: Pragmatic Project Automation

•Versionsmanagement ist selbstverständlich, oder?

o cvs, svn, etc.o alles, das nicht

automatisch generiert werden kann, liegt im Repository!

•Build Prozess auf separatem Build Server setzt auf das Repository auf (next slide)


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


Geschichtsbetrachtung1997

•Web Application Framework in C++ o Internet Banking Schweizer Grossbanko Online Game mit ca. 10000 userno Finanzinformationsportal mit 5 – 10000

gleichzeitig aktiven professionellen usern noch heute im Einsatz und aktiv weiterentwickelt

•1997 – keine automatischen Unit Testso jeder Entwickler/Applikation hat eigene Versiono Korrektur von Kernabstraktionen und

Infrastruktur notwendig, aber zu riskanto Refactoring-Stau


Ursachen1997•Furcht vor Änderungen am Framework

o Risiko: Destabilisierung existierenden Codeso Risiko: Change Propagation in „fertige“ Applikationeno Risiko: Mehraufwand für wiederholtes Testeno Risiken sind schwer einzuschätzen

•Qualitätsmängel im Frameworko FIXME Kommentare: quick hacks, trial and erroro Verwendung von C-legacy considered harmful: sscanf,

vprintf, char *o Teilweise unsauberes Verhalten im Multi-threaded Fallo Teilweise unsauberes Memory Management

Änderungen erfordern zu viel Mut und Angstschweiss, dass etwas kaputt geht


Vision 1998

1998: 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.


Was hat es gebracht? (1) 2000•Stabilität

o Grenzfälle besser abgedeckt z.b. 0, 1, viele, ganz viele, negativ ?

•Refactoring im Framework wurde möglicho z.B. Reduktion von unnötigem Locking,

optimiertes Memory Mgmt•Portabilität auf andere Plattformen

abgesichert o AIX, Windows NT, Teilbereiche auf exotisches IBM

Host OS (TPF)•Nachträgliche Implementierung von Tests

teilweise aufwändigo erste Tests teilweise zu umfangreich


Was hat es gebracht? (2) 2000•Austauschbarkeit von (ungünstigen)

Implementierungen o Elimination von C-Legacy und FIXMEs

•Besseres Interface Design von neuen Dingeno Test-first und Testability sind gute Ratgeber fürs

Schnittstellendesign•Einfachere Flexibilisierung•Vertrauen in „fremden“ Code bei Entwicklern gestiegen

o Konsolidierung von Codeo reduziertes Risiko, bzw. Risiko einschätzbar, indem man

Testcase schreibt, bevor man Änderung macht

Vorteile und Risikentestbasierter Entwicklung

anhand eigener Erfahrungen


Vorteile testbasierter Entwicklung (Entwickler)•Qualität des Codes gesteigert

o bei guten Testfällen, Grenzfälle abdecken•sicheres Refactoring wird ermöglicht

o kein Domino-Effekt bei Änderungen•gut testbarer Code hat besseres, einfacheres Design

o hohe Kohäsion, niedrigere Kopplung•Testcode macht Entwickler zum "Opfer" seines

Schnittstellendesignso bessere und einfacher nutzbare Interfaces

•Testcode dokumentiert Anforderungeno Test-First macht das explizit: zuerst die Anforderung als

Test kodieren•Debugger wird verzichtbar

o Bug wird im Testcase manifestiert, tritt nie wieder auf


Schwierigkeiten für Entwickler• Zeit, Coaching und Erfahrung nötig für gute Tests

o Support durch Kollegen und Führung!• Tests sind auch Code

o brauchen Refactoring• unnötige Tests behindern

o Plattformtests, "false positives" behinderno zu viele "Normalfälle" getestet

• Tests müssen rasch ablaufeno so oft wie möglich ausführen

• Tests müssen isoliert seino keine Abhängigkeiten von anderen Tests und Infrastruktur

Mock-Objekts einsetzen• Tests für existierenden Code schreiben ist schwerer

o oft zu viele Abhängigkeiten im Code -> schlechtes Design aber essentiell für Refactoring von "Altcode"

• schlechte Tests sind Hinweis auf schlechtes DesignHeute gibt es gute Literatur zum Thema.


Vorteile für Kunden

•Qualität der Lösung ist bessero oft schnellere, kostengünstigere Ergebnisseo keine lange Test- und Integrationsphase

notwendig•Änderungswünsche können ohne

Qualitätsrisiko rasch umgesetzt werdeno inkrementelle Entwicklung ist einfacher

•Wartung und Weiterentwicklung günstigero Fehler treten nur einmal aufo Fehler werden durch Tests erkannt und nicht erst

durch Anwender•Lebensdauer der Software ist länger


Risiken für Kunden

•Auf den ersten Blick sieht testbasierte Entwicklung teurer auso mehr Code zu schreibeno Refactoring bedeutet funktionierenden Code zu

ändern•Qualtiät kann "zu gut" sein

o interne 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ühreno innere Konflikte kommen heraus


Vorteile für Anbieter

•Hohe Qualität führt zu anerkannten Lösungeno Kundenzufriedenheit

•Zufriedene Entwicklero weniger Stress durch Sicherheitsnetz aus Tests

•Leichtere Einarbeitung neuen Personalso Tests verhindern "kaputtmachen"

•innere Qualtität des Codes kann verbessert werdeno Zukunftssicherung

•Portierbarkeit auf andere Plattformen


Risiken für Anbieter

•Qualität geschätzt aber Preis nicht gezahlto Kunde erkennt Agilität und nutzt Anbieter aus

•zufriedene Kunden kündigen Support & Wartungsverträgeo zu gute Qualität rächt sicho speziell bei Quellcodelieferung inkl. Testcases

•Schlechtere Softwarequalität führt zu mehr Kundenkontakteno bessere Kundenbindung, Projektpotential

•Neue Kunden sind schwer von Vorteilen zu überzeugeno Qualtiätsniveau ist (noch) nicht marktüblich


Zusammenfassung, Ausblick

•Ich bin "test-infiziert"o bereue jede eigene Entwicklung ohne Testso fordere konsequent von Studenten und

Mitarbeitern automatisierte Testso kenne Chancen aber auch mögliche Risiken und

Gegenmassnahmen

•Testbasierter Entwicklung gehört die Zukunfto Eclipse macht es vielen vor

auch wenn es selbst nur relativ wenige Testcases hato Bestandteil unserer Ausbildung an der HSRo gute Applikationstest tw. noch schwierig


Appell

•Lernen Sie, selbst testbasiert zu entwickelno unterstützen Sie Ihre Entwickler dabeio Praxis ist notwendigo Literatur unterstützt

•Erlauben Sie ihren Entwicklern testbasierte Entwicklung zu erlerneno beachten Sie die Lernkurve zum

Erfahrungsaufbau, es braucht Zeito Ausbildung, Übung, Literaturo einfach Anfangen, nicht Abwarten

•Fragen?


Literatur

• Andy Hunt, Dave Thomas, Mike Clark: Pragmatic Starter Kit: http://pragmaticprogrammer.com

o Pragmatic 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.: [email protected]

Lohnt sich testbasierte Software-Entwicklung iX Konferenz 2005: Bessere Software

Documents

Transcript of Lohnt sich testbasierte Software-Entwicklung iX Konferenz 2005: Bessere Software