Embed Size (px)
DESCRIPTION
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.
Citation preview
Und es geht doch ...TDD für
Benutzeroberflächen
Fabian Jakobs <[email protected]>qooxdoo Team <http://qooxdoo.org>
Montag, 8. Juni 2009
Agenda
• Was ist Test Driven Development?
• TDD für Benutzeroberflächen
• Beispiel
Montag, 8. Juni 2009
TDD
Montag, 8. Juni 2009
„Clean code that works“
Ron Jeffrie
Montag, 8. Juni 2009
Clean Code
Geringe Abhängigkeiten
Modular
Klares Design
Erweiterbar
Testbar
Montag, 8. Juni 2009
That Works
Erfüllt die Andorderungen
Performant
Robust
Rechtzeitig fertig
Zufriedene Anwender
Montag, 8. Juni 2009
CodeSchreiben Verwenden
Montag, 8. Juni 2009
TDD Gebote
• Rot
• Grün
• Refactor
Montag, 8. Juni 2009
Rot
„Du sollst keinen Prokuktivcode schreiben außer um einen
fehlschlagenden Test zu bestehen!“
Montag, 8. Juni 2009
CodeTest schreiben
Was erwarte ich vom Code?
Rot
Montag, 8. Juni 2009
Grün
„Du sollst möglichst einfachen Code schreiben um den Test so
schnell wie möglich zu bestehen!“
Montag, 8. Juni 2009
CodeSchreiben
Was ist der einfachste Code um den Test zu
bestehen?
Grün
Montag, 8. Juni 2009
Refactor
„Du sollst alle Redundanzen beseitigen, die gemacht wurden
um den Test zu bestehen!“
Montag, 8. Juni 2009
CodeSchreiben
Ich muss Redundanz beseitigen!
Refactor
Montag, 8. Juni 2009
„Edit and Pray“vs.
„Cover and Modify“Michael Feathers
Montag, 8. Juni 2009
Edit & Pray
• System analysieren
• Änderung durchführen
• Anwendung starten und Änderung überprüfen
• Anwendung „durchclicken“
Montag, 8. Juni 2009
Cover & Modify
• Test schreiben
• Änderung durchführen
• Alle Tests ausführen
Montag, 8. Juni 2009
Tests nehmen die Furcht versehentlich Fehler
einzuführen
„Diesen Teil des Programms ändere ich lieber nicht“
Montag, 8. Juni 2009
Tests sind Dokumentation
„Jeder Test ist ausführbarer Beispielcode“
Montag, 8. Juni 2009
Tests leiten das Design
„Wir betrachten das Programm aus Sicht der Anwender“
Montag, 8. Juni 2009
GUIs testen
Montag, 8. Juni 2009
TDD für GUIs
• GUI Code ist schwer zu testen
• GUI Code isolieren
• Komplexität gering halten
deshalb
Montag, 8. Juni 2009
Model-View-Controller (MVC)
Model
Controller
State Change
State Query
View
Zustand lesen
Change Notification
UpdateUser Event
Montag, 8. Juni 2009
Model-View-Presenter (MPV)
ModelPresenterView
Zustand lesen
State Query/Change
Change Notification
Update
User Event
Montag, 8. Juni 2009
Beispiel
Montag, 8. Juni 2009
View
• Properties
• Display
• Memory
• Operation
• Events
• Button press
Montag, 8. Juni 2009
Model (State Machine)
• States
• Number
• Wait for Number
• Error
• Properties
• State
• Input
• Value
• Error Message
• Memory
• Operation
• Methods
• Read Token
Montag, 8. Juni 2009
Presenter
• Properties
• State
• Input
• Value
• Error Message
• Memory
• Operation
• Methods
• Read Token
• Properties
• Display
• Memory
• Operation
• Events
• Button press
Presenter
ModelView
Montag, 8. Juni 2009
Presenter testen
ModelMockPresenterViewMock
Zustand lesen
PresenterTest
Montag, 8. Juni 2009
PresenterTest
Zustand lesen
Presenter testen
Montag, 8. Juni 2009
Events testen
Zustand lesen
ModelMockViewMock
Presenter
PresenterTest
Montag, 8. Juni 2009
Wie teste ich die View?
Montag, 8. Juni 2009
• API zum Presenter testen
• Vieles lässt sich automatisiert testen
„Verdrahtung“ testen
Montag, 8. Juni 2009
• Unterhalb der „echten“ Events ansetzen
• Evtl. Simulation von „echten“ Events
Events testen
Montag, 8. Juni 2009
• Themes sind auch Code
• Aussehen lässt sich kaum automatisiert testen
• View hat wenig Abhängigkeiten
• Kann isoliert ausgeführt werden
Aussehen testen
ABER
Montag, 8. Juni 2009
Mini-Programme
Montag, 8. Juni 2009
Fazit
TDD funktioniert für Benutzeroberflächern
wenndie Architektur stimmt
Montag, 8. Juni 2009
„Legacy code is code without tests“
Michael Feathers
Montag, 8. Juni 2009
Fragen?
Montag, 8. Juni 2009
Resourcen - Code
git clone git://github.com/fjakobs/Calculator.git
Montag, 8. Juni 2009
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
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
