Slides zur Session "Wie wird mein Code testbar?" auf den Berlin Expert Days 29.03.2012 Abstract: Soll ein Legacy System nachträglich um automatisierte Tests erweitert werden, so steht man gleich vor zwei Problemen auf einmal: einerseit verfügt das Team noch über wenig Test-Knowhow, andererseits ist Code schwer testbar, der nicht testgetrieben entwickelt wurde. So schwindet im Team schnell die Akzeptanz, automatisierte Tests zu schreiben: zu aufwändig! Der Vortrag stellt den Ansatz “Design for Testability” vor und illustiert anhand konkreter Java-Beispiele Potentiale zur Verbesserung der Testbarkeit, so dass Tests einfacher umgesetzt aber auch gewartet werden können.

1.
http://commons.wikimedia.org/wiki/File:Pit_crew_Hudson_Valley.JPG
Referent: David Völkel
Wie wird mein Code testbar?
http://commons.wikimedia.org/wiki/File:CarService.JPG

2.
David Völkel

3.
http://commons.wikimedia.org/wiki/File:Pit_crew_Hudson_Valley.JPG
http://commons.wikimedia.org/wiki/File:CarService.JPG
hard to test code
anti­pattern
Gute Testbarkeit

4.
Überblick
* Testbarkeit
* TDD vs. Legacy
* Isolation
* Ciao „accidental complexity“!

5.
Testbarkeit
http://commons.wikimedia.org/wiki/File:CarService.JPG
Kriterien
* operability
* decomposability
* observability
* controllability

6.
http://commons.wikimedia.org/wiki/File:CarService.JPG
Designziel
* wenig Testaufwand
Ursprung E­Technik
* Testschnittstellen
Design for Testability (DfT)

7.
Test Driven Development
vs.
Legacy

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

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

10.
write failing test
make the test
pass
(refactor)
Test Driven Development
(refactor)
Externe Qualität
Funktional
http://commons.wikimedia.org/wiki/File:Bluebird_land_speed_record_car_1935_rc10413.jpg

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

12.
* Drive Design
kontinuierlich
minimalistisch (YAGNI)
testbar <=> gutes Design
Test Driven Design
Code
Test
http://commons.wikimedia.org/wiki/File:Bluebird_land_speed_record_car_1935_rc10413.jpg

13.
* Drive Design
kontinuierlich
minimalistisch (YAGNI)
testbar <=> gutes Design
* Feedback auf Design
„Listen to your tests“!
(Zitat Johansen, 2010)
Test Driven Design
Code
Test
http://commons.wikimedia.org/wiki/File:Bluebird_land_speed_record_car_1935_rc10413.jpg

14.
Legacy Code
= keine Tests
schlecht testbares Design
* eigener Code
* 3rd
Party Code (Frameworks)
http://commons.wikimedia.org/wiki/File:Kopalnia_Wieczorek_rozbite_okna_12.08.jpg?uselang=de

15.
Legacy TDD
Renovierung
Doppelt schwierig
* Noch wenig KnowHow im Team
* Schwer testbarer Code
http://commons.wikimedia.org/wiki/File:Kopalnia_Wieczorek_rozbite_okna_12.08.jpg?uselang=de
http://commons.wikimedia.org/wiki/File:Bluebird_land_speed_record_car_1935_rc10413.jpg

16.
Legacy TDD
Renovierung
* „Lazy“
* Fixierung mit Systemtests
* Refactoring
* Unittests für neue Features
Nach Feathers 2004
http://commons.wikimedia.org/wiki/File:Kopalnia_Wieczorek_rozbite_okna_12.08.jpg?uselang=de
http://commons.wikimedia.org/wiki/File:Bluebird_land_speed_record_car_1935_rc10413.jpg

17.
Isolation

18.
Isolation
Test
Ziele
* Klarer Fokus
­ Testaufwand sinkt
­ Fehlerlokalisierung
einfacher
* Performanz
http://commons.wikimedia.org/wiki/File:Cocks_in_separate_cages,_Thailand.jpg

19.
front door
Test
* KEINE Isolation
* round trip tests
* state verification depended on components
(DOCs)
Testling
Begriffe nach Meszaros 2007
http://commons.wikimedia.org/wiki/File:Stork_Hotel_door.jpg

20.
back door
Begriffe nach Meszaros 2007
Test
„Mocks“
http://commons.wikimedia.org/wiki/File:Dummy_of_a_police_car.jpg
Unittests gegen
­ Blätter
­ „Units“ mit DOCs

21.
Isolierbarkeit
Problem:
Test Doubles nicht setzbar
Refactorings
Isolierbar
Test
Test
Doubles

22.
Beispiel: Logger

23.
Probleme
Observability (OUTPUT)
Controllability (INPUT)

24.
Ursachen
statische Abhängigkeiten
* Konstruktoraufrufe
* Singletons

25.
Statischer Aufruf => Objekte

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

27.
„Setzbarkeit“
Dependency Injection
* DOCs setzbar
* Konstruktor vs. Setter
* kein static
http://commons.wikimedia.org/wiki/File:Syringe_Glove_01.jpg

28.
Stub mit Bordmittel
* Input kontrollierbar
* etwas sperrig
Controllability (INPUT)

29.
Stub mit Mockframework
einfacher bei breiteren Interfaces

30.
Observability (OUTPUT)
Test Spy mit Bordmitteln

31.
* knapp
* „behavior verification“
Test Spy mit Mockframework

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

33.
...
Test
* Abhängigkeit explizit
* nur zu „Nachbarn“
Begriff „trainwreck code“ von Freeman / Price 2009
http://commons.wikimedia.org/wiki/File:1918trainwreck.jpg
Transitive Abhängigkeiten
GUI
Service

34.
Dependency Injection
Kontext Objekte
* kennen nur Nachbarn
Abhängigkeit
http://commons.wikimedia.org/wiki/File:Syringe_Glove_01.jpg

35.
Ciao „accidental complexity“!

36.
Ciao „accidental complexity“!
Problem:
* komplexe Setups
* schlechter Fokus
http://commons.wikimedia.org/wiki/File:US_Navy_040619­N­8704K­001_Boatswain_Mate_3rd_Class_Joanna_Saldana_cuts_the_rope_off_a_span_wire_aboard_the_aircraft_carrier_USS_John_F._Kennedy_
%28CV_67%29_during_an_underway_replenishment_.jpg?uselang=de

37.
Logische Fehler
* Schichten, z.B.
Prod­Code => Test­Code
* Zyklen
… und viele andere mehr!
http://de.wikipedia.org/w/index.php?title=Datei:Lattenkiste_a.jpg&filetimestamp=20060723120820

38.
Alles hängt von allem ab
Big Ball of Mud Separations
of
Concerns
System kleinschneiden
decomposability

39.
Fokus
SRP => Klasse
http://commons.wikimedia.org/wiki/File:Crossroads.jpg

40.
2 Aspekte auf einmal
...
Unfokussiert

41.
...
...
einfacher testbar
fokussierter
Extract Class Refactoring

42.
DfT
Strategie
Isolation
http://commons.wikimedia.org/wiki/File:US_Navy_040619­N­8704K­
001_Boatswain_Mate_3rd_Class_Joanna_Saldana_cuts_the_rope_off_a_span_wire_aboard_t
he_aircraft_carrier_USS_John_F._Kennedy_
%28CV_67%29_during_an_underway_replenishment_.jpg?uselang=de
http://commons.wikimedia.org/wiki/File:Cocks_in_separate_cages,_Thailand.jpg
Ciao
„accidental complexity“!
TDD

43.
Quellen
­ http://www.testbarkeit.de
­ http://en.wikipedia.org/wiki/Design_for_testing
­ Peter Zimmer, 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/
­ Christian Johansen, 2010: „Test­Driven JavaScript Development “
­ http://de.wikipedia.org/wiki/Gesetz_von_Demeter
­ Eric Evans, 2003: „Domain Driven Design“

44.
Fragen
und
Diskussion
http://commons.wikimedia.org/wiki/File:CarService.JPG

45.
Lizensiert unter Creative Commons 3.0 Attribution + Sharealike siehe
http://creativecommons.org/licenses/by­sa/3.0/deed.de