Test Driven Development und Continuous Integration. Mai 2017

Transkript

1 Test Driven Development und Continuous Integration Mai 2017

2 1. Motivation 2

3 Qualitätskrise Software wird zur Benutzung freigegeben, nicht wenn sie nachweislich korrekt ist, sondern wenn die Häufigkeit, mit der neue Fehler entdeckt werden, auf ein für die Geschäftsleitung akzeptables Niveau gesunken ist. - David L. Parnas 3

4 Qualitätskrise 4

5 Grundproblem Komplexe Modell Komplexe Interaktionen Viele Anforderungen Wenig Zeit Viel Konkurrenz Fehler sind kostspielig 5

6 Formale Verifikation Beweistechniken Semantikdefinitionen Zeit aufwändig Schlecht Abdeckung Nur bei kleinen Programmen anwendbar 6

7 2. Testing 7

8 Testing - Definition IEEE Std : (1) An activity in which a system or component is executed under specified conditions, the results are observed or recorded, and an evaluation is made of some aspect of the system or component. (2) To conduct an activity as in (1). 8

9 Aber 9

10 Aber 10

11 Testen kann immer nur die Anwesenheit aber nie die Abwesenheit von Fehlern zeigen. - Edsger Dijkstra 11

12 Voraussetzungen 12

13 Voraussetzungen 13

14 Voraussetzungen 14

15 Durchführung Ausgangszustand herstellen 15

16 Durchführung Ausgangszustand herstellen Testfalls ausführen 16

17 Durchführung Ausgangszustand herstellen Testfalls ausführen Soll-Ist-Vergleich 17

18 Durchführung Ausgangszustand herstellen Testfalls ausführen Soll-Ist-Vergleich Dokumentation 18

19 Testebenen Unit Tests 19

20 Testebenen Unit Tests Level 1 20

21 Testebenen Unit Tests Level 2 Level 1 21

22 Testebenen Unit Tests Level 3 Level 2 Level 1 22

23 Testebenen Level 4 Unit Tests Level 3 Level 2 Level 1 23

24 Testebenen Integration Tests Level 4 Unit Tests Level 3 Level 2 Level 1 24

25 Testebenen System Tests Integration Tests Level 4 Unit Tests Level 3 Level 2 Level 1 25

26 Testebenen User Acceptance Tests System Tests Integration Tests Level 4 Unit Tests Level 3 Level 2 Level 1 26

27 Tools Unit Test Framework: JUnit 4 + Hamcrest Mocking Framework: Mockito Code Quality: PMD, Findbugs, Checkstyle Code Coverage: Atlassian Clover, JaCoCo 27

28 Black-Box Tests Spezifikation Eingaben Erwartete Ausgaben 28

29 Black-Box Tests Spezifikation Eingaben Component under Test (cut) Ausgabe Erwartete Ausgaben 29

30 Glass-Box Tests Spezifikation + Metriken Eingaben Erwartete Ausgaben 30

31 Glass-Box Tests Spezifikation + Metriken Eingaben Component under Test (cut) Ausgabe Erwartete Ausgaben 31

32 Anweisungsüberdeckung (C 0 ) Mind. Einmal pro Anweisung a Wirksamkeit: Anzahl der ausgeführten Anweisungen Anzahl der aller Anweisungen b A1 Ja P1 Nein c Probleme - Kontrollflußfehler d Ja P2 Nein - Dead Code A2 e 32

33 Zweigüberdeckung (C 1 ) Mind. Einmal pro Zweig a Wirksamkeit: Anzahl der ausgeführten Zweige Anzahl der aller Zweige b A1 Ja P1 Nein c Probleme - Abhängigkeiten werden ignoriert c Ja P2 Nein - Schleifen - Komplexe Entscheidungen A2 d 33

34 Pfadüberdeckung (C 2 ) Mind. Einmal pro Pfad a Wirksamkeit: Anzahl der ausgeführten Pfade Anzahl der aller Pfade b A1 Ja P1 Nein c Probleme - Unerreichbare Pfade c Ja P2 Nein A2 d 34

35 3. Test Driven Development 35

36 Wie unterscheidet sich TDD? TDD beschäftigt sich mit Design Gibt Sicherheit Ermöglicht Veränderung Validiert Design Gibt schnelles Feedback Benötigt Diszipline 36

37 Ergebnisse Gesteigerte Qualität Lesbarkeit Wartbarkeit Simplizität Qualität bleibt erhalten Gutes Design 37

38 3 Grundregelen 1. Kein Produktionscode ohne eine scheiternden Test 2. Nicht mehr Testcode schreiben als zum scheitern nötig ist 3. Nicht mehr Producktionscode schreiben als nötig ist um den Test zu bestehen 38

39 Ablauf 1. Test schreiben 39

40 Ablauf 1. Test schreiben Test ist erfolgreich 2. Testergebnisse prüfen 40

41 Ablauf 1. Test schreiben Test ist erfolgreich 2. Testergebnisse prüfen Test scheitert 3. Code schreiben 41

42 Ablauf 1. Test schreiben Test ist erfolgreich 2. Testergebnisse prüfen Test scheitert 4. Testergebnisse prüfen 3. Code schreiben Test scheitert 42

43 Ablauf 1. Test schreiben Test ist erfolgreich 2. Testergebnisse prüfen Test scheitert 5. Refactor Code Test ist erfolgreich 4. Testergebnisse prüfen 3. Code schreiben Test scheitert 43

44 Ablauf 1. Test schreiben 6. Testergebnisse prüfen Test ist erfolgreich 2. Testergebnisse prüfen Test scheitert Test scheitert 5. Refactor Code Test ist erfolgreich 4. Testergebnisse prüfen 3. Code schreiben Test scheitert 44

45 Ablauf Test ist erfolgreich 1. Test schreiben 6. Testergebnisse prüfen Test ist erfolgreich 2. Testergebnisse prüfen Test scheitert Test scheitert 5. Refactor Code Test ist erfolgreich 4. Testergebnisse prüfen 3. Code schreiben Test scheitert 45

46 TDD und Design Loose Kopplung, Hoher Zusammenhalt Single Responsibility Principle Streben nach Einfachheit Modularisierung Encapsulation Duplikate vermeiden 46

47 TDD und Architektur Ersetzt nicht Architektur Design bleibt erforderlich, aber nicht im großen Stil Validiert Design Entscheidungen Deckt schwächen auf 47

48 Vorteile Besserer Vorschritt Besseres Design Bessere Entwickler Geringere Langzeitkosten 48

49 Best Practices Sofortiges Feedback Tests müssen schnell sein - In-Memory Datenbanken (H2, HSQL) Generierte Testdaten Testnamen sollten Zweck ausdrücken Unabhängige Tests Ein Konzept pro Test Ein Assert pro Test Augenscheinlich triviale Tests sind wichtig 49

50 Herausforderungen Disziplin Learning Curve Schlechte Angewohnheiten Wenig Rückenhalt 50

51 4. Continuous Integration 51

52 Ohne CI Selten Commits Schwierige Integration Viele Bugs Seltene Releases Spätes Testen 52

53 Bausteine von CI Zentrales Source Code Management Regelmäßige Commits Build Server Automatisierter Build Automatisierte Tests Codemetriken Zentrales Repository CI Tool 53

54 Entwicklung mit CI Stable v1 54

55 Entwicklung mit CI Stable Feature Branch v1 55

56 Entwicklung mit CI Stable c2 c1 Feature Branch v1 56

57 Entwicklung mit CI Stable v3 v2 c2 c1 Feature Branch v1 57

58 Entwicklung mit CI Stable v3 v2 c2 c1 Feature Branch v1 58

59 Entwicklung mit CI Pull-Request Master v3 v2 Stable v3 v2 c2 c1 Feature Branch v1 v1 59

60 Entwicklung mit CI c2 c1 Master v3 v2 Stable v3 v2 c2 c1 Feature Branch v1 v1 60

61 Entwicklung mit CI c2 c2 c1 c1 Master v3 v2 Stable v3 v2 c2 c1 Feature Branch v1 v1 61

62 Pro Schnelle Reaktionsfähigkeit Vertrauen in Software Bessere Zusammenarbeit Höhere Qualität 62

63 Contra Stabilität hängt von Testabdeckung ab Zeitinvestment Kulturschock Metriken und Monitoring erforderlich 63

64 Fragen?? 64

65 ipoint Weltweit Deutschland USA Österreich UK Japan ipoint-systems gmbh Reutlingen, Headquarters Ludwig-Erhard-Straße Reutlingen Tel Fax ipoint Inc. Ann Arbor 255 East Liberty, Suite 287 Ann Arbor, MI Tel Fax ipoint-austria GmbH Wien Ignaz-Köck-Straße 10 Top Wien Tel Fax info@ipoint-austria.at ipoint Ltd. Manchester Unit PO Box 4336 Manchester, M61 0BW Tel Fax info@ipoint-systems.com ipoint Japan Co Ltd Toiyo Oak Minami-Azabu Building 2F Minami-Azabu, Minato-ku Tokio, Japan Phone info-japan@ipoint-systems.com München Therese-Giehse-Platz Germering Tel Fax info.muc@ipoint-systems.de Los Angeles Magic Mountain Parkway, Suite 300 Valencia, CA T info@ipointinc.com Frankreich & Benelux ipoint-systems gmbh Paris Tel france@ipoint-systems.com Schweden ipoint-systems AB Växjö Framtidsvägen 16 SE Växjö Tel. +46 (70) info@ipoint-systems.se China ipoint Software and Information Technology (Shanghai) Ltd. Shanghai Room No. 331, Catering Part 2, 3F Huadu Building, Zhangyang Road , China (shanghai) Free Trade Pilot Zone Shanghai, China info-china@ipoint-systems.com Korea ipoint Korea Suwon Boeun bldg 304, Yeongtong 1-dong Yeongtong-gu Suwon-si, Gyeonggi-do Tel info-korea@ipoint-systems.com ipoint-systems.com

66 Copyright 2017 ipoint-systems gmbh All Rights Reserved No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of ipoint-systems gmbh. The information contained herein may be changed without prior notice. Some software products marketed by ipoint-systems gmbh and its distributors contain proprietary software components of other software vendors. Microsoft, Windows, Excel, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation. Oracle is a registered trademark of Oracle Corporation. HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C, World Wide Web Consortium, Massachusetts Institute of Technology. SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP Business ByDesign, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and other countries. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary. These materials are subject to change without notice. These materials are provided by ipoint-systems gmbh and its affiliated companies ( ipoint Group ) for informational purposes only, without representation or warranty of any kind, and ipoint Group shall not be liable for errors or omissions with respect to the materials. The only warranties for ipoint Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warrant. 66