Test DrivenDevelopment und...

Mai 2017

Test Driven Development und Continuous Integration

22

1. Motivation

© 2017 iPoint-systems gmbh

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

4

Qualitätskrise


5

Grundproblem


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

6

Formale Verifikation


• Beweistechniken• Semantikdefinitionen• Zeit aufwändig• Schlecht Abdeckung

Nur bei kleinen Programmen anwendbar

77

2. Testing


8

Testing - Definition


IEEE Std. 610.12-1990:(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).

9 © 2017 iPoint-systems gmbh

Aber…


Aber…


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


Voraussetzungen


Durchführung

Ausgangszustand herstellen


Durchführung


Testfalls ausführen


Durchführung



Soll-Ist-Vergleich


Durchführung



Soll-Ist-Vergleich

Dokumentation


Testebenen

Unit Tests


Testebenen

Unit Tests

Level 1


Testebenen

Unit Tests

Level 1

Level 2


Testebenen

Unit Tests

Level 1

Level 2

Level 3


Testebenen

Unit Tests

Level 1

Level 2

Level 3

Level 4


Testebenen

Integration Tests

Unit Tests

Level 1

Level 2

Level 3

Level 4


Testebenen

System Tests

Integration Tests

Unit Tests

Level 1

Level 2

Level 3

Level 4


Testebenen

User Acceptance Tests

System Tests

Integration Tests

Unit Tests

Level 1

Level 2

Level 3

Level 4

27

Tools


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

28

Black-Box Tests


Spezifikation

Eingaben

Erwartete Ausgaben

29

Black-Box Tests


Component under Test

(cut)

Spezifikation

Eingaben

Erwartete AusgabenAusgabe

30

Glass-Box Tests


Spezifikation + Metriken

Eingaben

Erwartete Ausgaben

31

Glass-Box Tests


Component under Test

(cut)

Spezifikation + Metriken

Eingaben

Erwartete AusgabenAusgabe

32

Anweisungsüberdeckung (C0)


• Mind. Einmal pro Anweisung• Wirksamkeit:

• Probleme- Kontrollflußfehler- Dead Code

P1

P2

A1

A2

NeinJa

e

bc

d

a

NeinJa

Anzahl der ausgeführten AnweisungenAnzahl der aller Anweisungen

33

Zweigüberdeckung (C1)


• Mind. Einmal pro Zweig• Wirksamkeit:

• Probleme- Abhängigkeiten werden ignoriert- Schleifen- Komplexe Entscheidungen

P1

P2

A1

A2

NeinJa

d

bc

c

a

NeinJa

Anzahl der ausgeführten ZweigeAnzahl der aller Zweige

34

Pfadüberdeckung (C2)


• Mind. Einmal pro Pfad• Wirksamkeit:

• Probleme- Unerreichbare Pfade

P1

P2

A1

A2

NeinJa

d

bc

c

a

NeinJa

Anzahl der ausgeführten PfadeAnzahl der aller Pfade

3535

3. Test Driven Development


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

37

Ergebnisse


• Gesteigerte Qualität• Lesbarkeit• Wartbarkeit• Simplizität• Qualität bleibt erhalten• Gutes Design

38

3 Grundregelen


1. Kein Produktionscode ohne eine scheiternden Test2. Nicht mehr Testcode schreiben als zum scheitern nötig ist3. Nicht mehr Producktionscode schreiben als nötig ist um den Test zu

bestehen


Ablauf

1. Test schreiben


Ablauf

1. Test schreiben

2. TestergebnisseprüfenTest ist erfolgreich


Ablauf

1. Test schreiben

2. Testergebnisseprüfen

3. Code schreiben

Test ist erfolgreich

Test scheitert


Ablauf

1. Test schreiben


3. Code schreiben



Test scheitert

Test scheitert


Ablauf

1. Test schreiben


3. Code schreiben5. Refactor

Code



Test scheitert

Test scheitert



Ablauf

1. Test schreiben



Code




Test scheitert

Test scheitert


Test scheitert


Ablauf

1. Test schreiben



Code




Test scheitert

Test scheitert



Test scheitert

46

TDD und Design


• Loose Kopplung, Hoher Zusammenhalt• Single Responsibility Principle• Streben nach Einfachheit• Modularisierung• Encapsulation• Duplikate vermeiden

47

TDD und Architektur


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

48

Vorteile


• Besserer Vorschritt• Besseres Design• Bessere Entwickler• Geringere Langzeitkosten

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

50

Herausforderungen


• Disziplin• Learning Curve• Schlechte Angewohnheiten• Wenig Rückenhalt

5151

4. Continuous Integration


52

Ohne CI…


• Selten Commits• Schwierige Integration• Viele Bugs• Seltene Releases• Spätes Testen

53

Bausteine von CI


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

54

Entwicklung mit CI


v1

Stab

le

55

Entwicklung mit CI


Feat

ure

Bran

ch

v1

Stab

le

56

Entwicklung mit CI


v1

Stab

le

c1

c2

Feat

ure

Bran

ch

57

Entwicklung mit CI


v1

v2

v3

Stab

le

c1

c2

Feat

ure

Bran

ch

58

Entwicklung mit CI


v1

v2

v3

Stab

le

c1

c2

Feat

ure

Bran

ch

59

Entwicklung mit CI


v1

v2

v3St

able

c1

c2

Feat

ure

Bran

ch

v1

v2

v3

Mas

ter

Pull-Request

60

Entwicklung mit CI


v1

v2

v3St

able

c1

c2

Feat

ure

Bran

ch

v1

v2

v3

Mas

ter

c1

c2

61

v1

v2

v3St

able

c1

c2

Entwicklung mit CI


c1

c2

Feat

ure

Bran

ch

v1

v2

v3

Mas

ter

c1

c2

62

Pro


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

63

Contra


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

6464

Fragen??


iPoint Weltweit

ipoint-systems.com

USAiPoint Inc.Ann Arbor255 East Liberty, Suite 287Ann Arbor, MI 48104Tel. +1 248 282-4085Fax +1 248 [email protected]

Los Angeles25350 Magic Mountain Parkway, Suite 300Valencia, CA 91355T +1 [email protected]

DeutschlandiPoint-systems gmbh Reutlingen, HeadquartersLudwig-Erhard-Straße 5872760 ReutlingenTel. +49 7121 14489-60Fax +49 7121 [email protected]

MünchenTherese-Giehse-Platz 682110 GermeringTel. +49 89 800 6588-18Fax +49 89 800 [email protected]

UKiPoint Ltd.ManchesterUnit 10135PO Box 4336Manchester, M61 0BWTel. +44 1204 819051Fax +44 1942 [email protected]

ChinaiPoint Software and Information Technology (Shanghai) Ltd.ShanghaiRoom No. 331, Catering Part 2, 3F Huadu Building,Zhangyang Road 828 – 838,China (shanghai) Free Trade Pilot ZoneShanghai, [email protected]

KoreaiPoint KoreaSuwonBoeun bldg 304, 1029-8 Yeongtong 1-dongYeongtong-gu443 815 Suwon-si, Gyeonggi-doTel. +82 [email protected]

JapaniPoint Japan Co LtdToiyoOak Minami-Azabu Building 2F3-19-23 Minami-Azabu, Minato-kuTokio, Japan 106-0047Phone +81 3 4580 [email protected]

ÖsterreichiPoint-Austria GmbHWienIgnaz-Köck-Straße 10Top 3.041210 WienTel. +43 1 2720370-10Fax +43 1 [email protected]

Schweden iPoint-systems ABVäxjöFramtidsvägen 16SE-351 96 VäxjöTel. +46 (70) [email protected]

Frankreich & BeneluxiPoint-systems gmbhParisTel. +33 788 919 985 [email protected]

66

• 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.

Copyright 2017 iPoint-systems gmbh All Rights Reserved


Test DrivenDevelopment und...

Documents

Transcript of Test DrivenDevelopment und...