Design for Testability in der Praxis David Völkel, codecentric AG

Transkript

1 Design for Testability in der Praxis David Völkel, codecentric AG

2 David Völkel *

3 anti-pattern hard to test code Gute Testbarkeit

4 Überblick * Testbarkeit * Test Driven Design vs. Legacy * Isolation * Isolierende Refactorings

5 Testbarkeit = Aufwand fürs Testen Kriterien * operability * decomposability * observability * controllability

6 Design for Testability (DfT) Designziel * wenig Testaufwand Ursprung E-Technik Tests SUT

7 Design for Testability (DfT) Designziel * wenig Testaufwand Ursprung E-Technik * Testschnittstellen Tests SUT

8 Test Driven Design vs. Legacy

9 Test Driven Development write failing test (refactor) make the test pass

10 Test Driven Development write failing test (refactor) (refactor) make the test pass

11 Test Driven Development write failing test (refactor) (refactor) make the test pass Externe Qualität Funktional

12 Test Driven Development write failing test (refactor) (refactor) make the test pass Externe Qualität Funktional Interne Qualität => Test Driven Design

13 Qualität durch Redundanz 2x * Problem * Sprache * Personen Code Test * deklarativ * beispielhaft * algorithmisch

14 Test Driven Design Test * Drive Design kontinuierlich minimalistisch (YAGNI) testbar <=> gutes Design (Designskills unabdingbar) Code

15 Test Driven Design Test * Drive Design kontinuierlich minimalistisch (YAGNI) testbar <=> gutes Design (Designskills unabdingbar) Code

16 Test Driven Design * Drive Design kontinuierlich minimalistisch (YAGNI) testbar <=> gutes Design (Designskills unabdingbar) * Feedback auf Design Listen to your tests! Test Code

17 Legacy Code = keine Tests schlecht testbares Design * eigener Code * 3rd Party Code (Frameworks)

18 Legacy TDD Renovierung Doppelt schwierig * Im Team noch wenig KnowHow (TDD, Design) * Schwer testbarer Code

19 Legacy TDD Renovierung * Lazy * Fixierung mit Systemtests * Refactoring * TDD / Unittests für neue Features Nach Feathers 2004

20 Isolation

21 front door * KEINE Isolation * integration / round trip tests Test Testling depended on components (DOCs) Begriffe nach Meszaros

22 integration tests are a scam (J.B. Rainsberger)

23 back door collaboration tests * Unittests * mit Test Doubles Test Mocks Begriffe nach Meszaros

24 contract tests * erfüllt DOC den Contract? * abgestimmt mit collaboration tests Begriffe nach J.B. Rainsberger Test

25 Blätter Unittests gegen Blätter * Isolation geschenkt Test

26 Isolation Test Nutzen * Klarer Fokus - Testbarkeit - Fehlerlokalisierung - Wartbarkeit * Performanz => schnelleres Feedback * Weniger Testfälle a * b => a + b

27 Problem GUI Testing? Keine Isolation => schlechte Wartbarkeit => schlechte Performance => schlechte Fehlerlokalisierung => fehleranfällig

28 Testpyramide GUI * Testcoverage API / Service Component / Integration Unit

29 Isolation vs. ATDD / Outside-In?

30 Isolation vs. ATDD / Outside-In? * Outside-In geht auch gegen API * GUI Tests isolieren * Integration testen, nicht Funktionalitäten der Beteiligten

31 Isolierbarkeit Test Problem: Test Doubles nicht setzbar Test Doubles

32 Isolierbarkeit Test Problem: Test Doubles nicht setzbar Refactorings Isolierbar Test Doubles

33 Isolierende Refactorings

34 Beispiel: Logger

35 Probleme Controllability (INPUT) Observability (OUTPUT)

36 Ursachen statische Abhängigkeiten * Konstruktoraufrufe * Singletons

37 Statischer Aufruf => Objekte Zitat aus Freeman / Pryce 2009

38 Statischer Aufruf => Objekte Klasse <=> * weniger Aufwand * don't mock concrete classes Zitat aus Freeman / Pryce 2009 Interface * Abhängigkeiten expliziter geringer (ISP) * Semantik durch Rollen

39 Setzbarkeit Dependency Injection * DOCs setzbar * Konstruktor vs. Setter * kein static

40 Stub mit Bordmittel Controllability (INPUT) * Input kontrollierbar

41 Stub mit Mockframework * einfacher bei breiteren Interfaces

42 Test Spy mit Bordmitteln Observability (OUTPUT)

43 Test Spy mit Mockframework * knapp * behavior verification

44 Transitive Abhängigkeiten trainwreck code Begriff von Freeman / Price Problem: Implizite Abhängigkeiten GUI Test Service

45 Transitive Abhängigkeiten... * Abhängigkeit explizit * nur zu Nachbarn GUI Test Service Begriff trainwreck code von Freeman / Price 2009

46 Dependency Injection Kontext Abhängigkeit Objekte * kennen nur Nachbarn

47 Fokus SRP => Klasse

48 Unfokussiert... 2 Aspekte auf einmal

49 Extract Class Refactoring fokussierter... einfacher testbar...

50 Designprobleme Testbarkeit

51 Designprobleme Testbarkeit * Abhängigkeitszyklen * fachlich nicht begründetete Abhängigkeiten * accidental complexity * Status im Testling * u.v.m.

52 Listen DfT Strategie TDD Isolation

53 Quellen Peter Zimmerer, 2012: Testability A Lever to Build Sustaining Systems, OOP Conference Steve Freeman, Nat Pryce, 2009: Growing Object-Oriented Software guided by Tests - Micheal Feathers, 2004: Working effectively with legacy systems - Robert C. Martin, 2009: Clean Code - Gerard Meszaros, 2007: xunit Test Patterns bzw Testing Pyramid: - Mike Cohn, the forgotten layer of the test automation pyramid J.B. Rainsberger: Integrations tests are a scam

54 Fragen und Diskussion!

55 Lizensiert unter Creative Commons 3.0 Attribution + Sharealike siehe