Post on 03-Aug-2020
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
http://commons.wikimedia.org/wiki/File:CarService.JPG
hard to test codeanti-pattern
Gute Testbarkeit
Überblick* Testbarkeit* Test Driven Design vs. Legacy* Isolation * Isolierende Refactorings
Testbarkeit
http://commons.wikimedia.org/wiki/File:CarService.JPG
= Aufwand fürs TestenKriterien* operability* decomposability* observability* controllability
http://commons.wikimedia.org/wiki/File:CarService.JPG
Designziel* wenig Testaufwand
Ursprung E-Technik
Design for Testability (DfT)
Tests SUT
http://commons.wikimedia.org/wiki/File:CarService.JPG
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)
Test Driven Development
(refactor)
http://commons.wikimedia.org/wiki/File:Bluebird_land_speed_record_car_1935_rc10413.jpg
write failing test
make the test pass
(refactor)
Test Driven Development
(refactor)
Externe QualitätFunktional
http://commons.wikimedia.org/wiki/File:Bluebird_land_speed_record_car_1935_rc10413.jpg
write failing test
make the test pass
(refactor)
Test Driven Development
(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
http://commons.wikimedia.org/wiki/File:Bluebird_land_speed_record_car_1935_rc10413.jpg
* Drive Designkontinuierlichminimalistisch (YAGNI)testbar <=> gutes Design(Designskills unabdingbar)
Test Driven Design
Code
Test
http://commons.wikimedia.org/wiki/File:Bluebird_land_speed_record_car_1935_rc10413.jpg
* Drive Designkontinuierlichminimalistisch (YAGNI)testbar <=> gutes Design(Designskills unabdingbar)
* 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
* 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.de- http://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“
Fragen und
Diskussion!
http://commons.wikimedia.org/wiki/File:CarService.JPG
Lizensiert unter Creative Commons 3.0 Attribution + Sharealike siehehttp://creativecommons.org/licenses/by-sa/3.0/deed.de