Das Dokument behandelt die Testbarkeit von Code und die Herausforderungen im Zusammenhang mit 'legacy code', einschließlich der Unterschiede zwischen testgetriebenem Design und altem Code. Es werden Kriterien wie Beobachtbarkeit, Steuerbarkeit und Zerlegbarkeit angesprochen sowie Methoden zur Verbesserung der Testbarkeit wie Dependency Injection und Refactoring. Zentrale Konzepte sind 'accidental complexity' und die Notwendigkeit, Designstrategien zu nutzen, um die Testbarkeit zu fördern.

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