Test Driven Development ist eines der wichtigsten Methoden aus dem Extreme Programming um hohe Softwarequalität zu garantieren und agil auf Änderungen reagieren zu können. Es hält sich allerdings sehr hartnäckig die Legende, dass man TDD für die Entwicklung von Benutzeroberlächen nicht anwenden kann. In diesem Vortrag werden Architekturansätze und Techniken vorgestellt, die es erlauben testbare Benutzeroberflächen zu schreiben.

1. Und es geht doch ...
TDD für
Benutzeroberflächen
Fabian Jakobs <fabian.jakobs@1und1.de>
qooxdoo Team <http://qooxdoo.org>
Montag, 8. Juni 2009

2. Agenda
• Was ist Test Driven Development?
• TDD für Benutzeroberflächen
• Beispiel
Montag, 8. Juni 2009

3. TDD
Montag, 8. Juni 2009

4. „Clean code that works“
Ron Jeffrie
Montag, 8. Juni 2009

5. Clean Code
Klares Design Testbar
Modular
Geringe Erweiterbar
Abhängigkeiten
Montag, 8. Juni 2009

6. That Works
Performant Rechtzeitig
fertig
Erfüllt die
Andorderungen
Robust Zufriedene
Anwender
Montag, 8. Juni 2009

7. Schreiben Verwenden
Code
Montag, 8. Juni 2009

8. TDD Gebote
•Rot
• Grün
• Refactor
Montag, 8. Juni 2009

9. Rot
„Du sollst keinen Prokuktivcode
schreiben außer um einen
fehlschlagenden Test zu bestehen!“
Montag, 8. Juni 2009

10. Rot
Was erwarte ich
vom Code?
Test schreiben
Code
Montag, 8. Juni 2009

11. Grün
„Du sollst möglichst einfachen
Code schreiben um den Test so
schnell wie möglich zu bestehen!“
Montag, 8. Juni 2009

12. Grün
Was ist der
einfachste Code
um den Test zu
bestehen?
Schreiben
Code
Montag, 8. Juni 2009

13. Refactor
„Du sollst alle Redundanzen
beseitigen, die gemacht wurden
um den Test zu bestehen!“
Montag, 8. Juni 2009

14. Refactor
Ich muss
Redundanz
beseitigen!
Schreiben
Code
Montag, 8. Juni 2009

15. „Edit and Pray“
vs.
„Cover and Modify“
Michael Feathers
Montag, 8. Juni 2009

16. Edit & Pray
• System analysieren
• Änderung durchführen
• Anwendung starten und
Änderung überprüfen
• Anwendung „durchclicken“
Montag, 8. Juni 2009

17. Cover & Modify
• Test schreiben
• Änderung durchführen
• Alle Tests ausführen
Montag, 8. Juni 2009

18. Tests nehmen die Furcht
versehentlich Fehler
einzuführen
„Diesen Teil des Programms ändere ich lieber nicht“
Montag, 8. Juni 2009

19. Tests sind Dokumentation
„Jeder Test ist ausführbarer Beispielcode“
Montag, 8. Juni 2009

20. Tests leiten das Design
„Wir betrachten das Programm aus Sicht
der Anwender“
Montag, 8. Juni 2009

21. GUIs testen
Montag, 8. Juni 2009

22. TDD für GUIs
• GUI Code ist schwer zu testen
deshalb
• GUI Code isolieren
• Komplexität gering halten
Montag, 8. Juni 2009

23. Model-View-Controller (MVC)
Controller
User Event Update State Change
Change Notification
View Model
State Query
Montag, 8. Juni 2009 Zustand lesen

24. Model-View-Presenter (MPV)
User Event Change Notification
View Presenter Model
Update State Query/Change
Montag, 8. Juni 2009 Zustand lesen

25. Beispiel
Montag, 8. Juni 2009

26. View
• Properties
• Display
• Memory
• Operation
• Events
• Button press
Montag, 8. Juni 2009

27. Model (State Machine)
• States
• Number
• Wait for Number
• Error
• Properties
• State
• Input
• Value
• Error Message
• Memory
• Operation
• Methods
• Read Token
Montag, 8. Juni 2009

28. Presenter
View Model
P
• Properties
r
• Properties
e • State
• Display
s • Input
• Memory e • Value
n • Error Message
• Operation
t • Memory
• Events e • Operation
r • Methods
• Button press
• Read Token
Montag, 8. Juni 2009

29. Presenter testen
PresenterTest
ViewMock Presenter ModelMock
Montag, 8. Juni 2009 Zustand lesen

30. Presenter testen
PresenterTest
Montag, 8. Juni 2009 Zustand lesen

31. Events testen
PresenterTest
ModelMock
ViewMock
Presenter
Montag, 8. Juni 2009 Zustand lesen

32. Wie teste ich die View?
Montag, 8. Juni 2009

33. „Verdrahtung“ testen
• API zum Presenter testen
• Vieles lässt sich automatisiert testen
Montag, 8. Juni 2009

34. Events testen
• Unterhalb der „echten“ Events ansetzen
• Evtl. Simulation von „echten“ Events
Montag, 8. Juni 2009

35. Aussehen testen
• Themes sind auch Code
• Aussehen lässt sich kaum automatisiert
testen
ABER
• View hat wenig Abhängigkeiten
• Kann isoliert ausgeführt werden
Montag, 8. Juni 2009

36. Mini-Programme
Montag, 8. Juni 2009

37. Fazit
TDD funktioniert für
Benutzeroberflächern
wenn
die Architektur stimmt
Montag, 8. Juni 2009

38. „Legacy code is code
without tests“
Michael Feathers
Montag, 8. Juni 2009

39. Fragen?
Montag, 8. Juni 2009

40. Resourcen - Code
git clone git://github.com/fjakobs/Calculator.git
Montag, 8. Juni 2009

41. Resourcen / TDD
• Literatur
• „Test Driven Development by Example“, Kent Beck
• „Working Effectively with Legacy Code“, Michael
Feathers
• „Clean Code: A Handbook of Agile Software
Craftsmanship“, Robert C. Martin
• Präsentationen im Netz
• „Test Driven Development?“, Frederik Kalseth
http://iridescence.no/post/Slides-From-my-TDD-
Talk.aspx
• „Test Driven Development Best Practices for
Eclipse RCP“, Kevin Taylor, http://live.eclipse.org/
node/700
Montag, 8. Juni 2009

42. Resourcen / MVP
• Martin Fowler
• Passive View, http://www.martinfowler.com/eaaDev/
PassiveScreen.html
• GUI Architectures, http://www.martinfowler.com/eaaDev/
uiArchs.html
• Microsoft
• View Testability, http://msdn.microsoft.com/en-us/library/
cc304742.aspx
• Design Patterns - Model View Presenter, http://
msdn.microsoft.com/de-de/magazine/cc188690(en-us).aspx
• „Build Your Own CAB“, Jeremey D. Miller, http://
codebetter.com/blogs/jeremy.miller/archive/2007/07/25/the-
build-your-own-cab-series-table-of-contents.aspx
Montag, 8. Juni 2009