Best Practices für den Entwicklertest

Transkript

1 Best Practices für den Entwicklertest

2 Am 4. Juni 1996 wurde der Prototyp der Ariane- 5-Rakete der ESA eine Minute nach dem Start in vier Kilometern Höhe gesprengt, weil der Programmcode, der von der Ariane 4 übernommen worden war und nur für einen von der Ariane 4 nicht überschreitbaren Bereich (Beschleunigungswert) funktionierte, die Steuersysteme zum Erliegen brachte, als eben dieser Bereich von der Ariane 5, die stärker als die Ariane 4 beschleunigt, überschritten wurde. Zu Beginn des Jahres 2010 konnten wegen eines Softwarefehlers im EMV-Sicherheitschip bei der Verarbeitung der Jahreszahl 2010 viele Bankkunden tagelang an Automaten kein Geld abheben Best Practices für den Entwicklertest Markus Job, Christian Schubert JBFOne 2010 Seite 2

3 Ziele dieses Vortrags Ziele und Nutzen der Entwicklertestmethodik Nutzen der frühen Tests für Entwickler und QS Unterschied zwischen Komponenten und Komponentenintegrationstest Best Practice für den Entwicklertest Nutzen von statischer Codeanalyse und Testautomation Überblick unterstützender Werkzeuge Best Practices für den Entwicklertest Markus Job, Christian Schubert JBFOne 2010 Seite 3

4 Agenda Ziele und Nutzen der Entwicklertest-Methodik Ziele des Entwicklertests Best Practices für den Entwicklertest Fazit/Zusammenfassung Fragen? Diskussion? Best Practices für den Entwicklertest Markus Job, Christian Schubert JBFOne 2010 Seite 4

5 Ziele / Nutzen der Entwicklertestmethodik Warum optimieren wir die Methodik? Standardisierung und Professionalisierung der Entwicklertests durch den Einsatz aktueller und erprobter Methoden und Werkzeuge Qualitätsverbesserungen bereits in früher Implementierungsphase Definition einheitlicher und skalierbarer Vorgaben für den Entwicklertest (Berücksichtigung von Neu- und Weiterentwicklung) Kostenreduzierung bei PJ/AM durch die zentrale Bereitstellung von Methoden und Werkzeugen in den vorhandenen Entwicklungsumgebungen Schnelle Einarbeitung und Orientierung neuer Mitarbeiter (intern/extern) durch Schulungsbausteine, Entwicklerkompass und Entwicklertest-Support Wiederverwendbarkeit der Entwicklertestfälle für Wartung und Weiterentwicklung Transparenz über Inhalte und Ergebnisse aus den Entwicklertests für Folgeteststufen Best Practices für den Entwicklertest Markus Job, Christian Schubert JBFOne 2010 Seite 5

7 Ziele der Entwicklertests Sicherstellen, dass die Komponente die laut ihrer Spezifikation geforderten Funktionalität korrekt und vollständig realisiert ist Funktionalität ist dabei gleichbedeutend mit dem Ein- und Ausgabeverhalten der zu testenden Komponente Test auf Robustheit verfolgt das Ziel, Fehlersituationen abzufangen und robust darauf zu reagieren Die neuen/geänderten Masken werden korrekt nach dem UI-Styleguide umgesetzt Entwicklertest prüft die Komponenteneigenschaft auf Änderbarkeit/Wartbarkeit (statische Codeanalyse) Frühes Fehlerfinden erspart Zeit und Aufwand für die Bereinigung Reduzierung der Bugfixingaufwände (Analyse, Korrektur, Build und Übergabe) für Fehler aus Folgeteststufen Best Practices für den Entwicklertest Markus Job, Christian Schubert JBFOne 2010 Seite 7

8 Gemeinsames Verständnis des Entwicklertests Jeder schreibt JUnit-Tests, aber JUnit ist nur ein Werkzeug die Erwartung, was damit getestet wird, geht weit auseinander Komponententests/Unittests Habe ich richtig programmiert? Konzentration auf kleinste sinnvoll testbare Einheit/Unit (z. B. Klasse, Service) Eher technischer Fokus Verhält sich die zu testende Komponente wie erwartet? Positive und negative Wertprüfungen Komponentenintegrationstests Habe ich das Richtige programmiert? Test der Schnittstellen zwischen Units Eher fachlicher Fokus Funktioniert die Interaktion mehrerer Komponenten? Unterstützungsmöglichkeit durch Tester Best Practices für den Entwicklertest Markus Job, Christian Schubert JBFOne 2010 Seite 8

10 Continuous Integration Regelmäßige Ausführung automatisierter Testfälle Hudson als Continuous Integration-Server steuert regelmäßige Builds (nightly) Compilieren entsprechend der Regeln des zentralen Builds Ausführen der automatisierten Testfälle Durchführen von dynamischer Analyse und statischer Codeanalyse Entwicklertest- Methodik: Build Test Quellcoderepository Projektkonfiguration Metriken Deliverable Repository Allgemein: Build Test Paketierung Übergabe Build-Ergebnisse (inklusive Testdurchführung und Codeanalysen) stehen unabhängig vom Entwicklerarbeitsplatz für alle Projektmitarbeiter bereit Best Practices für den Entwicklertest Markus Job, Christian Schubert JBFOne 2010 Seite 10

11 Continuous Integration Regelmäßige Ausführung automatisierter Testfälle und was haben die Entwickler davon? Hudson als Continuous Integration-Server steuert regelmäßige Builds (nightly) Verteilter Aufwand für KMV Compilieren entsprechend der Regeln des Zentralen Builds (nicht konzentriert zu Release-Terminen) Ausführen der automatisierten Testfälle Durchführen von Dynamischer Entwickler Analyse muss und sich Statischer nicht selbst Codeanalyse um die regelmäßige Ausführung der Tests kümmern Entwicklertest- Methodik: Build Ergebnisse sind für Nicht-Entwickler unabhängig Test von Eclipse verfügbar Quellcoderepository Projektkonfiguration Metriken Deliverable Repository Allgemein: Build Test Paketierung Übergabe Build-Ergebnisse (inkl. Testdurchführung und Codeanalysen) stehen unabhängig vom Entwicklerarbeitsplatz für alle Projektmitarbeiter zur Verfügung Best Practices für den Entwicklertest Markus Job, Christian Schubert JBFOne 2010 Seite 11

12 Automatisierte Testausführung Dynamische Analyse Anzahl und Ergebnisse der Entwicklertests %-Satz der ausgeführten Anweisungen durch automatisiert durchgeführte Entwicklertests Die Metriken der dynamischen Analyse werden während der Durchführung der Entwicklertests gemessen für aussagekräftige Analysen sollten möglichst viele Testfälle automatisiert ausführbar sein Best Practices für den Entwicklertest Markus Job, Christian Schubert JBFOne 2010 Seite 12

13 Dynamische Analyse Anzahl und Ergebnisse der Entwicklertests und was haben die Entwickler davon? Regelmäßige automatische Testausführung %-Satz der ausgeführten Anweisungen durch automatisiert durchgeführte Testergebnisse werden dokumentiert Entwicklertests Erkennen von nicht getestetem Quellcode (Zur Absicherung zusätzliche Testfälle erstellen) Die Metriken der Dynamischen Analyse werden während der Durchführung der Entwicklertests gemessen für aussagekräftige Analysen sollten möglichst viele Testfälle automatisiert ausführbar sein Best Practices für den Entwicklertest Markus Job, Christian Schubert JBFOne 2010 Seite 15

14 Best Practices für JUnit Design for Test/Test first Testbarer Code Vermeidung unnötiger Abhängigkeiten Isolation von Abhängigkeiten Konsequente Implementierung gegen Interfaces Trennung von fachlichem und technischem/technologieabhängigen Code Kombination aus Test first und Ergänzung der Testfälle nach der Implementierung Qualitätssicherung der Testfälle Reviews auf die Testfälle Bei Fehlerbehebung werden entsprechende Testfälle erstellt Jeder Testfall funktioniert eigenständig und unabhängig Der Testfall hat keine Seiteneffekte Es muss möglich sein, den Testfall ohne manuellen Eingriff zu wiederholen Der Testfall ist zeitunabhängig und funktioniert auch in der Zukunft prüft das erwartete Ergebnis Es werden nicht nur Positiv-Fälle getestet Mittels assert( )- und fail( )- Methoden wird das erwartete Ergebnis geprüft und unerwartetes Verhalten signalisiert ist klein und fokussiert Jeweils nur ein Aspekt wird gestestet Best Practices für den Entwicklertest Markus Job, Christian Schubert JBFOne 2010 Seite 16

15 Best Practices für JUnit und was haben die Entwickler davon? Design for Test / Test first Es entsteht Jeder testbarer Testfall Quellcode Testbarer Code Mehr Testfälle können funktioniert automatisiert eigenständig werden und unabhängig Vermeidung unnötiger Abhängigkeiten Verbesserung der Der Testabdeckung Testfall hat keine Seiteneffekte Isolation von Abhängigkeiten Es muss möglich sein den Testfall ohne Konsequente Implementierung Die Testfälle gegen sind aussagekräftig manuellen Eingriff und zu wiederholen Interfaces unterstützen bei der Der Fehlerfindung Testfall ist zeitunabhängig und Trennung von fachlichem und funktioniert auch in der Zukunft technischem/technologieabhängigen Know-how- und Erfahrungsaustausch bei Reviews Code prüft das erwartete Ergebnis Es werden nicht nur Positiv Fälle Kombination aus Test first und Ergänzung getestet der Testfälle nach der Implementierung Mittels assert( )- und fail( )- Methoden wird das erwartete Ergebnis Qualitätssicherung der Testfälle geprüft bzw. unerwartetes Verhalten signalisiert Reviews auf die Testfälle Bei Fehlerbehebung werden entsprechende Testfälle erstellt ist klein und fokussiert Es wird jeweils nur ein Aspekt gestestet Best Practices für den Entwicklertest Markus Job, Christian Schubert JBFOne 2010 Seite 17

16 Test Doubles Konzentration auf die zu testende Komponente Die meisten nicht trivialen Einheiten haben Abhängigkeiten zu anderen Einheiten der Software oder zu externer Infrastruktur Diese anderen Einheiten und die externe Infrastruktur müsste für jeden Testfall bereitgestellt werden, damit er durchgeführt werden kann Stattdessen werden Test Doubles verwendet Sie imitieren das für den Testfall relevante Verhalten der echten Abhängigkeiten Sie sind dumme Objekte und enthalten keine Fachlogik sowie keine Abhängigkeiten zu anderen Einheiten oder zu externer Infrastruktur Mock-ups Durch Mock-up-Frameworks werden zur Testdurchführung Implementierungen von Interfaces bereitgestellt Konzentration auf das für den Testfall relevante Verhalten Mock-ups können das Verhalten der zu testenden Einheit aufzeichnen und gegen das erwartete Verhalten kann geprüft werden Best Practices für den Entwicklertest Markus Job, Christian Schubert JBFOne 2010 Seite 18

17 Test Doubles Konzentration auf die zu testende Komponente Die meisten nicht trivialen Einheiten haben Abhängigkeiten zu anderen Einheiten der Software oder zu externer Infrastruktur Diese anderen Einheiten bzw. die externe Infrastruktur müsste für jeden Testfall bereitgestellt werden, damit Fokussierung durchgeführt der werden Testfälle kann möglich Stattdessen werden Test Doubles Testfälle verwendet ohne externe Infrasturktur möglich Imitieren das für den Testfall relevante Verhalten der echten Abhängigkeiten Sind dumme Objekte und enthalten Durch Mock-ups keine Fachlogik weniger Aufwand sowie keine Abhängigkeiten zu anderen Einheiten oder zu externer zur Erstellung Infrastruktur von Test Doubles Mock-ups und was haben die Entwickler davon? Durch Mock-up-Frameworks werden zur Testdurchführung Implementierungen von Interfaces bereitgestellt Konzentration sich auf das für den Testfall relevante Verhalten Mock-ups können das Verhalten der zu testenden Einheit aufzeichnen und es kann gegen das erwartete Verhalten geprüft werden Best Practices für den Entwicklertest Markus Job, Christian Schubert JBFOne 2010 Seite 19

18 Testbarkeit Gut automatisiert testbar Abgeschlossene Logik Hilfs-, Utility- Methoden Masken Controller Automatisiert testbar Data Services Application Services Momentan nicht automatisiert testbar Zugriffe auf den Host (Transaction Services) Zugriffe auf Verbundsysteme Masken Hinweise JUnit Durchreicheservices nicht sinnvoll Hinweise Test Doubles Refactoring aktuell nicht testbarer Services Hinweise Manuelle Ausführung in Eclipse Best Practices für den Entwicklertest Markus Job, Christian Schubert JBFOne 2010 Seite 20

19 Umgang mit nicht automatisierbaren Testfällen GUI (BAP) UI-Entwicklertest-Checkliste Dezentraler Server (Tomcat) AS DS TS JUnittestfälle Trotzdem JUnits schreiben, auch wenn diese (momentan) in Continuous Integration nicht ausgeführt werden können Datenbank (DB2) Zentraler Server (Host) Manuelle Ausführung (wie bisher) ist weiterhin möglich und gewünscht Quelle: JBFOne 2009 / JBF inside / Unit-Tests für JBF-Services, Gert Lormes (AEW6TA) Best Practices für den Entwicklertest Markus Job, Christian Schubert JBFOne 2010 Seite 21

20 Umgang mit nicht automatisierbaren Testfällen GUI (BAP) und was haben die Entwickler davon? UI-Entwicklertest-Checkliste Checkliste unterstützt beim Testen von Masken Orientierungshilfe für neue GUI-Entwickler Dezentraler Server (Tomcat) AS Leicht wiederholbare Testfälle (auch wenn diese nicht in Continuous Integration ausgeführt werden) DS TS JUnittestfälle Trotzdem JUnits schreiben, auch wenn diese (momentan) in Continuous Integration nicht ausgeführt werden können Datenbank (DB2) Zentraler Server (Host) Manuelle Ausführung (wie bisher) ist weiterhin möglich und gewünscht Quelle: JBFOne 2009 / JBF inside / Unit-Tests für JBF-Services, Gert Lormes (AEW6TA) Best Practices für den Entwicklertest Markus Job, Christian Schubert JBFOne 2010 Seite 23

21 Automatisiertes Code-Review Statische Code-Analyse Code-Reviews der implementierten Komponenten und Entwicklertestfälle Erkennen von Code-Duplikaten Finden von offenen Punkten Erkennen potentiell fehlerhafter Codefragmente (Bug Patterns) Finden von Verstößen gegen die Coding Standards Die zu prüfenden Komponenten werden nicht ausgeführt Best Practices für den Entwicklertest Markus Job, Christian Schubert JBFOne 2010 Seite 24

22 Automatisierte Code-Reviews und was haben die Entwickler davon? Statische Code-Analyse Code-Duplikate in nicht generiertem Code können zu Code-Reviews der implementierten Problemen in der Wartung führen Komponenten und Entwicklertestfälle Erkennen von Code-Duplikaten Offene Punkte helfen nichts zu vergessen Finden von Offenen Punkten Erkennen potentiell fehlerhafter Automatisierte Codefragmente Code-Reviews (Bug Patterns) melden zeitnah potentielle Probleme Finden von Verstößen gegen die Coding Standards Die zu prüfenden Komponenten werden nicht ausgeführt. Wartbarer Code durch Einhaltung gemeinsamer Regeln Best Practices für den Entwicklertest Markus Job, Christian Schubert JBFOne 2010 Seite 27

24 Fazit/Zusammenfassung Entwicklertest-Landkarte (Dezentral) Circle Test Komponententest vs Komponentenintegrationstest Test-Doubles easymock JMockit thirdparty-test Formulare Eingangsprüfung IKESA-Simulator IKESA-Analyzer TS Daten-Konvertierung Host Java AS Test-Doubles JUnit Best Practices DS DDSteps Eigenes DB-Schema FIT DbSetup Continuous Integration Schnittstellen Verbund Cronacle (Jobsteuerung) Cronacles (Java-Jobs) BAP-Vereinfachung Berücksichtigung der Testbarkeit Infrastruktur Codeabdeckung Statische Codeanalyse Checkstyle PMD Findbugs Sotograph Migration DAM JPL HDC HcRuntime Innovation (KVP) BAP-Client (Frontlet-Tester) UI Defect Detector BAP-Checkliste (TAFF) JFCUnit Jnlp-Runner DEV-Launcher Fehlende Inhalte In Arbeit befindliche Inhalte Vorhandene Inhalte Best Practices für den Entwicklertest Markus Job, Christian Schubert JBFOne 2010 Seite 29

25 Fazit/Zusammenfassung Softwarequalitäts-Eisberg Wartungskosten Fehlerfreiheit Zuverlässigkeit Leistungsfähigkeit Testbarkeit Test Externe Qualität Sichtbare Symptome Testbarer Quellcode entsteht Verbesserung der Testabdeckung Die Testfälle sind aussagekräftig und unterstützen bei der Fehlerfindung Regelmäßige automatische Testausführung Komplexität Kodierregeln Wiederverwendbarkeit Lesbarkeit Wartbarkeit Review Interne Qualität Unsichtbare Symptome Wartbarer Code durch Einhaltung gemeinsamer Regeln und Verringerung von Code-Duplikaten Offene Punkte helfen nichts zu vergessen Automatisierte Code-Reviews melden zeitnah potenzielle Probleme Best Practices für den Entwicklertest Markus Job, Christian Schubert JBFOne 2010 Seite 30

26 Literatur Test Doubles, Mockups Eine Übersicht der verschiedenen Arten von Test Doubles findet sich bei Martin Fowler: Dynamische Analyse/Statische Codeanalyse, Metriken Robert C. Martin: Clean Code Entwicklertestfälle/JUnit Gerard Meszaros: xunit Test Patterns Best Practices für den Entwicklertest Markus Job, Christian Schubert JBFOne 2010 Seite 31

28 Fragen? Diskussion? Best Practices für den Entwicklertest Markus Job, Christian Schubert JBFOne 2010 Seite 33

29 Fragen? Diskussion? Christian Schubert Capgemini 0711 / Markus Job AEW7QR Testberater / Testmanager markus.job@fiducia.de / Best Practices für den Entwicklertest Markus Job, Christian Schubert JBFOne 2010 Seite 34

30 Ihr IT-Partner Vielen Dank