„Design for Testability“ in der Praxis€¦ · David Völkel * @davidvoelkel *

http://commons.wikimedia.org/wiki/File:Pit_crew_Hudson_Valley.JPG

David Völkel, codecentric AG

„Design for Testability“ in der Praxis

http://commons.wikimedia.org/wiki/File:CarService.JPG

David Völkel* @davidvoelkel* https://www.xing.com/profile/David_Voelkel

http://commons.wikimedia.org/wiki/File:Pit_crew_Hudson_Valley.JPG


hard to test codeanti-pattern

Gute Testbarkeit

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

Testbarkeit


= Aufwand fürs TestenKriterien* operability* decomposability* observability* controllability


Designziel* wenig Testaufwand

Ursprung E-Technik

Design for Testability (DfT)

Tests SUT


Designziel* wenig Testaufwand

Ursprung E-Technik* Testschnittstellen

Design for Testability (DfT)

Tests SUT

Test Driven Design vs. Legacy

write failing test

make the test pass

(refactor)

Test Driven Development

http://commons.wikimedia.org/wiki/File:Bluebird_land_speed_record_car_1935_rc10413.jpg

write failing test

make the test pass

(refactor)


(refactor)


write failing test

make the test pass

(refactor)


(refactor)

Externe QualitätFunktional


write failing test

make the test pass

(refactor)


(refactor)

Externe QualitätFunktional

Interne Qualität=> Test Driven Design

Qualität durch Redundanz

http://commons.wikimedia.org/wiki/File:PC-Netzteil_%28redundant%29.jpg

CodeTest

2x ●* Problem ●* Sprache●* Personen

●* deklarativ●* beispielhaft

●* algorithmisch

* Drive Designkontinuierlichminimalistisch (YAGNI)testbar <=> gutes Design(Designskills unabdingbar)

Test Driven Design

Code

Test



Test Driven Design

Code

Test



* Feedback auf Design„Listen to your tests“!

Test Driven Design

Code

Test

http://commons.wikimedia.org/wiki/File:1948_Hans_Breinlinger_-_Clown_mit_Spiegel.jpg

Legacy Code= keine Testsschlecht testbares Design

* eigener Code* 3rd Party Code (Frameworks)

http://commons.wikimedia.org/wiki/File:Kopalnia_Wieczorek_rozbite_okna_12.08.jpg?uselang=de

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

http://commons.wikimedia.org/wiki/File:Kopalnia_Wieczorek_rozbite_okna_12.08.jpg?uselang=dehttp://commons.wikimedia.org/wiki/File:Bluebird_land_speed_record_car_1935_rc10413.jpg


Legacy TDDRenovierung* „Lazy“* Fixierung mit Systemtests* Refactoring * TDD / Unittests für neue Features

Nach Feathers 2004

http://commons.wikimedia.org/wiki/File:Kopalnia_Wieczorek_rozbite_okna_12.08.jpg?uselang=dehttp://commons.wikimedia.org/wiki/File:Bluebird_land_speed_record_car_1935_rc10413.jpg


Isolation

front doorTest

* KEINE Isolation* integration / round trip tests

depended on components (DOCs)

Testling

Begriffe nach Meszaros 2007http://commons.wikimedia.org/wiki/File:Stork_Hotel_door.jpg

„integration tests are a scam“(J.B. Rainsberger)

back door

Begriffe nach Meszaros 2007

„Mocks“

http://commons.wikimedia.org/wiki/File:Dummy_of_a_police_car.jpg

„collaboration tests“* Unittests * mit Test Doubles

Test

contract tests

Begriffe nach J.B. Rainsbergerhttp://commons.wikimedia.org/wiki/File:Dummy_of_a_police_car.jpg

* erfüllt DOC den Contract?

* abgestimmt mit collaboration tests

Test

Blätter

http://commons.wikimedia.org/wiki/File:Dummy_of_a_police_car.jpg

Unittests gegen Blätter* Isolation geschenkt

Test

IsolationNutzen* Klarer Fokus

- Testbarkeit- Fehlerlokalisierung - Wartbarkeit

* Performanz=> schnelleres

Feedback* Weniger Testfälle a * b => a + b

http://commons.wikimedia.org/wiki/File:Cocks_in_separate_cages,_Thailand.jpg

Test

Problem GUI Testing?

Keine Isolation=> schlechte Wartbarkeit=> schlechte Performance=> schlechte Fehlerlokalisierung => fehleranfällig

http://upload.wikimedia.org/wikipedia/commons/9/97/Fire_2011.jpg?uselang=de

Testpyramide

GUI

API / Service Component / Integration

Unit http://commons.wikimedia.org/wiki/File:Piramida_Cheopsa.jpg

* Testcoverage

Isolation vs.

ATDD / Outside-In?

http://commons.wikimedia.org/wiki/File:Actress-fear-and-panic.jpg

http://commons.wikimedia.org/wiki/File:Actress-fear-and-panic.jpg

* Outside-In geht auch gegen API* GUI Tests isolieren* Integration testen,

nicht Funktionalitäten der Beteiligten

Isolation vs.

ATDD / Outside-In?

Isolierbarkeit

Problem:Test Doubles nicht setzbar

Test

Test Doubles

Isolierbarkeit

Problem:Test Doubles nicht setzbar

Refactorings

Isolierbar

Test

Test Doubles

Isolierende Refactorings

Beispiel: Logger

Probleme

Observability (OUTPUT)

Controllability (INPUT)

Ursachen

statische Abhängigkeiten* Konstruktoraufrufe* Singletons

Statischer Aufruf => Objekte

Zitat aus Freeman / Pryce 2009

Statischer Aufruf => Objekte

Interface* Abhängigkeiten

explizitergeringer (ISP)

* Semantik durch Rollen

Klasse <=>* weniger Aufwand* „don't mock concrete

classes“

Zitat aus Freeman / Pryce 2009

„Setzbarkeit“

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

http://commons.wikimedia.org/wiki/File:Syringe_Glove_01.jpg

Stub mit Bordmittel

* Input kontrollierbar

Controllability (INPUT)

Stub mit Mockframework

* einfacher bei breiteren Interfaces

Observability (OUTPUT)

Test Spy mit Bordmitteln

* knapp* „behavior verification“

Test Spy mit Mockframework

...

Test

GUI

Service

„trainwreck code“Begriff von Freeman / Price 2009

http://upload.wikimedia.org/wikipedia/commons/b/b5/Durango_Silverton_Train.jpg?uselang=de

Transitive Abhängigkeiten

Problem: Implizite Abhängigkeiten

...

Test

* Abhängigkeit explizit* nur zu „Nachbarn“

Begriff „trainwreck code“ von Freeman / Price 2009http://commons.wikimedia.org/wiki/File:1918trainwreck.jpg

Transitive Abhängigkeiten

GUI

Service

Dependency Injection

Kontext Objekte* kennen nur Nachbarn

Abhängigkeit

http://commons.wikimedia.org/wiki/File:Syringe_Glove_01.jpg

FokusSRP => Klasse

http://commons.wikimedia.org/wiki/File:Crossroads.jpg

2 Aspekte auf einmal

...

Unfokussiert

...

...

einfacher testbar

fokussierter

Extract Class Refactoring

Design-probleme

Testbarkeit

http://commons.wikimedia.org/wiki/File:Policedog01.JPG

Design-probleme

Testbarkeit

http://commons.wikimedia.org/wiki/File:Policedog01.JPG

* Abhängigkeitszyklen* fachlich nicht

begründetete Abhängigkeiten

* accidental complexity* Status im Testling* u.v.m. …

DfT Strategie

Isolationhttp://commons.wikimedia.org/wiki/File:Cocks_in_separate_cages,_Thailand.jpg

TDDhttp://commons.wikimedia.org/wiki/File:Bluebird_land_speed_record_car_1935_rc1

0413.jpg

http://commons.wikimedia.org/wiki/File:1948_Hans_Breinlinger_-_Clown_mit_Spiegel.jpg

Listen

Quellen- http://www.testbarkeit.dehttp://en.wikipedia.org/wiki/Design_for_testing- Peter Zimmerer, 2012: Testability – A Lever to Build Sustaining Systems,

OOP Conference 2012- http://secs.ceas.uc.edu/~cpurdy/sefall11/testing_payneetal_1997.pdf

- 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. http://xunitpatterns.com/- http://de.wikipedia.org/wiki/Gesetz_von_Demeter- Testing Pyramid:

- Mike Cohn, „the forgotten layer of the test automation pyramid„- http://blogs.agilefaqs.com/2011/02/01/inverting-the-testing-pyramid/

- J.B. Rainsberger: „Integrations tests are a scam“

http://www.testbarkeit.de/

http://en.wikipedia.org/wiki/Design_for_testing

http://secs.ceas.uc.edu/~cpurdy/sefall11/testing_payneetal_1997.pdf

http://xunitpatterns.com/

http://de.wikipedia.org/wiki/Gesetz_von_Demeter

http://www.mountaingoatsoftware.com/blog/the-forgotten-layer-of-the-test-automation-pyramid

http://blogs.agilefaqs.com/2011/02/01/inverting-the-testing-pyramid/

Fragen und

Diskussion!


Lizensiert unter Creative Commons 3.0 Attribution + Sharealike siehehttp://creativecommons.org/licenses/by-sa/3.0/deed.de

Documents

„Design for Testability“ in der Praxis€¦ · David Völkel * @davidvoelkel *