Wie wird mein Code testbar?
45
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
-
Upload
david-voelkel -
Category
Software
-
view
71 -
download
2
description
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.
Transcript of Wie wird mein Code testbar?
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
David Völkel
http://commons.wikimedia.org/wiki/File:Pit_crew_Hudson_Valley.JPG
http://commons.wikimedia.org/wiki/File:CarService.JPG
hard to test codeantipattern
Gute Testbarkeit
Überblick* Testbarkeit* TDD vs. Legacy* Isolation* Ciao „accidental complexity“!
Testbarkeit
http://commons.wikimedia.org/wiki/File:CarService.JPG
Kriterien* operability* decomposability* observability* controllability
http://commons.wikimedia.org/wiki/File:CarService.JPG
Designziel* wenig Testaufwand
Ursprung ETechnik* Testschnittstellen
Design for Testability (DfT)
Test Driven Development 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
* Drive Designkontinuierlichminimalistisch (YAGNI)testbar <=> gutes Design
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
* 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
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* Noch wenig KnowHow im Team* 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 * 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
IsolationTest
Ziele* Klarer Fokus
Testaufwand sinkt Fehlerlokalisierung
einfacher* Performanz
http://commons.wikimedia.org/wiki/File:Cocks_in_separate_cages,_Thailand.jpg
front doorTest
* KEINE Isolation* round trip tests* state verification depended on components
(DOCs)
Testling
Begriffe nach Meszaros 2007http://commons.wikimedia.org/wiki/File:Stork_Hotel_door.jpg
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
Isolierbarkeit
Problem:Test Doubles nicht setzbar
Refactorings
Isolierbar
Test
Test Doubles
Beispiel: Logger
Probleme
Observability (OUTPUT)
Controllability (INPUT)
Ursachen
statische Abhängigkeiten* Konstruktoraufrufe* Singletons
Statischer Aufruf => Objekte
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* etwas sperrig
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
Ciao „accidental complexity“!
Ciao „accidental complexity“!
Problem:* komplexe Setups* schlechter Fokus
http://commons.wikimedia.org/wiki/File:US_Navy_040619N8704K001_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
Logische Fehler* Schichten, z.B.
ProdCode => TestCode* Zyklen … und viele andere mehr!
http://de.wikipedia.org/w/index.php?title=Datei:Lattenkiste_a.jpg&filetimestamp=20060723120820
Alles hängt von allem ab
Big Ball of Mud Separations of
Concerns
System kleinschneiden
decomposability
FokusSRP => Klasse
http://commons.wikimedia.org/wiki/File:Crossroads.jpg
2 Aspekte auf einmal
...
Unfokussiert
...
...
einfacher testbar
fokussierter
Extract Class Refactoring
DfTStrategie
Isolation
http://commons.wikimedia.org/wiki/File:US_Navy_040619N8704K001_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
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 ObjectOriented 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: „TestDriven JavaScript Development “ http://de.wikipedia.org/wiki/Gesetz_von_Demeter Eric Evans, 2003: „Domain Driven Design“
Fragen und
Diskussion
http://commons.wikimedia.org/wiki/File:CarService.JPG
Lizensiert unter Creative Commons 3.0 Attribution + Sharealike siehehttp://creativecommons.org/licenses/bysa/3.0/deed.de
