Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.
   
http://commons.wikimedia.org/wiki/File:Pit_crew_Hudson_Valley.JPG
Referent: David Völkel
Wie wird mein Code testbar?
h...
   
                 David Völkel
   
http://commons.wikimedia.org/wiki/File:Pit_crew_Hudson_Valley.JPG
http://commons.wikimedia.org/wiki/File:CarService.JP...
   
Überblick
* Testbarkeit
* TDD vs. Legacy
* Isolation
* Ciao „accidental complexity“!
   
Testbarkeit
http://commons.wikimedia.org/wiki/File:CarService.JPG
Kriterien
* operability
* decomposability
* observab...
   
http://commons.wikimedia.org/wiki/File:CarService.JPG
Designziel
* wenig Testaufwand
Ursprung E­Technik
* Testschnitts...
   
Test Driven Development 
vs. 
Legacy
   
write failing test
make the test 
pass
(refactor)
Test Driven Development
http://commons.wikimedia.org/wiki/File:Blueb...
   
write failing test
make the test 
pass
(refactor)
Test Driven Development
(refactor)
http://commons.wikimedia.org/wiki...
   
write failing test
make the test 
pass
(refactor)
Test Driven Development
(refactor)
Externe Qualität
Funktional
http:...
   
write failing test
make the test 
pass
(refactor)
Test Driven Development
(refactor)
Externe Qualität
Funktional
Inter...
   
* Drive Design
kontinuierlich
minimalistisch (YAGNI)
testbar <=> gutes Design
Test Driven Design
Code
Test
http://comm...
   
* Drive Design
kontinuierlich
minimalistisch (YAGNI)
testbar <=> gutes Design
* Feedback auf Design
„Listen to your te...
   
Legacy Code
= keine Tests
schlecht testbares Design
* eigener Code
* 3rd
 Party Code (Frameworks)
http://commons.wikim...
   
Legacy TDD
Renovierung
Doppelt schwierig
* Noch wenig KnowHow im Team
* Schwer testbarer Code
http://commons.wikimedia...
   
Legacy TDD
Renovierung
* „Lazy“
* Fixierung mit Systemtests
* Refactoring 
* Unittests für neue Features
Nach Feathers...
   
Isolation
   
Isolation
Test
Ziele
* Klarer Fokus
­ Testaufwand sinkt
­ Fehlerlokalisierung 
einfacher
* Performanz
http://commons.w...
   
front door
Test
* KEINE Isolation
* round trip tests
* state verification depended on components 
(DOCs)
Testling
Begr...
   
back door
Begriffe nach Meszaros 2007
Test
„Mocks“
http://commons.wikimedia.org/wiki/File:Dummy_of_a_police_car.jpg
Un...
   
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 
expliziter
geringer (ISP)
* Semantik durch Rollen
 
Klasse   ...
   
„Setzbarkeit“
Dependency Injection
* DOCs setzbar
* Konstruktor vs. Setter
* kein static
http://commons.wikimedia.org/...
   
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/...
   
...
Test
* Abhängigkeit explizit
* nur zu „Nachbarn“
Begriff „trainwreck code“ von Freeman / Price 2009
http://commons...
   
Dependency Injection
Kontext Objekte
* kennen nur Nachbarn
Abhängigkeit
http://commons.wikimedia.org/wiki/File:Syringe...
   
Ciao „accidental complexity“!
   
Ciao „accidental complexity“!
Problem:
* komplexe Setups
* schlechter Fokus
http://commons.wikimedia.org/wiki/File:US_...
   
Logische Fehler
* Schichten, z.B.
Prod­Code => Test­Code
* Zyklen 
… und viele andere mehr!
http://de.wikipedia.org/w/...
   
Alles hängt von allem ab
Big Ball of Mud Separations 
of 
Concerns
System kleinschneiden 
decomposability
   
Fokus
SRP => Klasse
http://commons.wikimedia.org/wiki/File:Crossroads.jpg
   
2 Aspekte auf einmal
...
Unfokussiert
   
...
...
einfacher testbar
fokussierter
Extract Class Refactoring
   
DfT
Strategie
Isolation
http://commons.wikimedia.org/wiki/File:US_Navy_040619­N­8704K­
001_Boatswain_Mate_3rd_Class_Jo...
   
Quellen
­ http://www.testbarkeit.de
­ http://en.wikipedia.org/wiki/Design_for_testing
­ Peter Zimmer, 2012: Testabilit...
   
Fragen 
und 
Diskussion
http://commons.wikimedia.org/wiki/File:CarService.JPG
   
Lizensiert unter Creative Commons 3.0 Attribution + Sharealike siehe
http://creativecommons.org/licenses/by­sa/3.0/dee...
Nächste SlideShare
Wird geladen in …5
×

Wie wird mein Code testbar?

576 Aufrufe

Veröffentlicht am

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.

Veröffentlicht in: Software
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Wie wird mein Code testbar?

  1. 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. 2.                      David Völkel
  3. 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. 4.     Überblick * Testbarkeit * TDD vs. Legacy * Isolation * Ciao „accidental complexity“!
  5. 5.     Testbarkeit http://commons.wikimedia.org/wiki/File:CarService.JPG Kriterien * operability * decomposability * observability * controllability
  6. 6.     http://commons.wikimedia.org/wiki/File:CarService.JPG Designziel * wenig Testaufwand Ursprung E­Technik * Testschnittstellen   Design for Testability (DfT) 
  7. 7.     Test Driven Development  vs.  Legacy
  8. 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. 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. 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. 11.     write failing test make the test  pass (refactor) Test Driven Development (refactor) Externe Qualität Funktional Interne Qualität => Test Driven Design
  12. 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. 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. 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. 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. 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. 17.     Isolation
  18. 18.     Isolation Test Ziele * Klarer Fokus ­ Testaufwand sinkt ­ Fehlerlokalisierung  einfacher * Performanz http://commons.wikimedia.org/wiki/File:Cocks_in_separate_cages,_Thailand.jpg
  19. 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. 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. 21.     Isolierbarkeit Problem: Test Doubles nicht setzbar Refactorings Isolierbar Test Test  Doubles
  22. 22.     Beispiel: Logger
  23. 23.     Probleme Observability (OUTPUT) Controllability (INPUT) 
  24. 24.     Ursachen statische Abhängigkeiten * Konstruktoraufrufe * Singletons
  25. 25.     Statischer Aufruf => Objekte
  26. 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. 27.     „Setzbarkeit“ Dependency Injection * DOCs setzbar * Konstruktor vs. Setter * kein static http://commons.wikimedia.org/wiki/File:Syringe_Glove_01.jpg
  28. 28.     Stub mit Bordmittel * Input kontrollierbar * etwas sperrig Controllability (INPUT) 
  29. 29.     Stub mit Mockframework einfacher bei breiteren Interfaces
  30. 30.     Observability (OUTPUT)  Test Spy mit Bordmitteln 
  31. 31.     * knapp * „behavior verification“ Test Spy mit Mockframework 
  32. 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. 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. 34.     Dependency Injection Kontext Objekte * kennen nur Nachbarn Abhängigkeit http://commons.wikimedia.org/wiki/File:Syringe_Glove_01.jpg
  35. 35.     Ciao „accidental complexity“!
  36. 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. 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. 38.     Alles hängt von allem ab Big Ball of Mud Separations  of  Concerns System kleinschneiden  decomposability
  39. 39.     Fokus SRP => Klasse http://commons.wikimedia.org/wiki/File:Crossroads.jpg
  40. 40.     2 Aspekte auf einmal ... Unfokussiert
  41. 41.     ... ... einfacher testbar fokussierter Extract Class Refactoring
  42. 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. 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. 44.     Fragen  und  Diskussion http://commons.wikimedia.org/wiki/File:CarService.JPG
  45. 45.     Lizensiert unter Creative Commons 3.0 Attribution + Sharealike siehe http://creativecommons.org/licenses/by­sa/3.0/deed.de

×