Hendrik Lösch
Hendrik.Loesch@saxsys.de
just-about.net
@HerrLoesch
Qualität.
Aber bitte agil!!!
Speichern

Benutzersicht

Gespeichert
Speichern

Benutzersicht

Anbindung UI

Architektursicht

Anbindung
Datenbank

Fehlerbehandlung
Validator

Datenvalidierung

Benutzersicht

Button

Entwicklersicht

Fehlerbehandlung

Fehlerausschrift

Datenbankanbindun...
Systemtests
Unit-Tests
Validator

Datenvalidierung

Benutzersicht

Button

Entwicklersicht

Fehlerbehandlung

Fehleraussch...
„Nichts ist so beständig wie die Veränderung.“
Bob Dylan
„Wer als einziges Werkzeug einen Hammer hat,
sieht in jedem Problem einen Nagel.“
Paul Watzlawick
Manuelle
Tests

Systemtests

Integrationstests

UnitTests
Vertrauen

Feedback

Aufwand
Tue nur Dinge
die einen
Mehrwert
bedeuten!
Tue nur Dinge
die einen
Mehrwert ???
bedeuten.
Tue nur Dinge
die einen
Feedback !!!
bedeuten.
Implementierung

Test

Refaktorisierung
Die Regeln
•
•
•
•

Schreibe nur Code, der verlangt wird.
Entwickle schrittweise Deinen Code.
Wähle möglichst kleine Schri...
Implementierung

Test

Refaktorisierung
System-Tests
Unit-Tests
Validator

Datenvalidierung

Benutzersicht

Button

Entwicklersicht

Fehlerbehandlung

Fehleraussc...
Validator

Datenvalidierung

Entwicklersicht

Fehlerbehandlung

Fehlerausschrift

Datenbankanbindung

Button

Validierungs...
Qualität ist wichtiger als Quantität
Hump of Pain
“New teams are often expected to adopt practices such as TDD
and refactoring, which are difficult to learn. W...
Pragmatisch
Eher Test First als Test Driven
Eher Komponententests als Unit-Tests
Eher interaktionsbasierend als
statusbasi...
Systemtest

Integrationstest

Unit-Test

Quelle: Succeeding with Agile, Mike Cohn
Implementierung

Systemtest

Test

Refaktorisierung
System-Tests
Unit-Tests
Validator

Datenvalidierung

Benutzersicht

Button

Entwicklersicht

Fehlerbehandlung

Fehleraussc...
System-Test

Speichern

DB

Benutzersicht

Extern
System-Test

Unit-Tests

Speichern

Button

Datenbankanbindung

Speichervorgang

DB

Zurücksetzen
bei Fehler

Benutzersich...
Problem
verstehen

Grobdesign
(„Architektur“)

Automatisierung
•
Build
•
Deployment
•
End-To-End
Tests

Produktinkrement

...
Inside-Out TDD
Implementierung geschieht vor allem im BL.
Anbindung externer Ressourcen nachträglich
über System Tests.

O...
Inside-Out TDD

Outside-In TDD

Mehr statusbasierende Tests.
Vor allem in „weniger“ agilen Teams zu finden.

Mehr interakt...
Gherkin
Funktionalität: Nächster Arbeitsschritt nach der Bilderauswahl
Damit die ausgewählten Bilder weiter verarbeitet we...
Gherkin
Funktionalität: Nächster Arbeitsschritt nach der Bilderauswahl
Damit die ausgewählten Bilder weiter verarbeitet we...
Happy Path!!!
Quelle: Growing Object oriented Software guided by Tests
Vertrauen

Feedback
Aufwand
Hendrik Lösch
Hendrik.Loesch@saxsys.de
just-about.net
@HerrLoesch
Transformation Priority Premise
({} → nil)
(nil → constant)
(constant → constant+)
(constant → scalar)
(statement → statem...
Fast
Isolated
Independent
Repeatable
Self-Verifying
Timely
“

The SOLID principles are not rules. They are not laws. They are not
perfect truths. They are statements on the order of...
S
O
L
I
D

ingle Responsibility Principle
pen Closed Principle
iskov Substitution Principle
nterface Segregation Principle...
S
O
L
I
D

ingle Responsibility Principle
pen Closed Principle
iskov Substitution Principle
nterface Segregation Principle...
S
O
L
I
D

ingle Responsibility Principle
pen Closed Principle
iskov Substitution Principle
nterface Segregation Principle...
S
O
L
I
D

ingle Responsibility Principle
pen Closed Principle
iskov Substitution Principle
nterface Segregation Principle...
S
O
L
I
D

ingle Responsibility Principle
pen Closed Principle
iskov Substitution Principle
nterface Segregation Principle...
S
O
L
I
D

ingle Responsibility Principle
pen Closed Principle
iskov Substitution Principle
nterface Segregation Principle...
Qualität, aber bitte agil.
Qualität, aber bitte agil.
Qualität, aber bitte agil.
Qualität, aber bitte agil.
Qualität, aber bitte agil.
Nächste SlideShare
Wird geladen in …5
×

Qualität, aber bitte agil.

813 Aufrufe

Veröffentlicht am

Der Vortrag beschreibt die unterschiedlichen Schulen und Ausprägungen des Test Driven Development.

Veröffentlicht in: Technologie
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

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

Keine Downloads
Aufrufe
Aufrufe insgesamt
813
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
235
Aktionen
Geteilt
0
Downloads
0
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Qualität, aber bitte agil.

  1. 1. Hendrik Lösch Hendrik.Loesch@saxsys.de just-about.net @HerrLoesch
  2. 2. Qualität. Aber bitte agil!!!
  3. 3. Speichern Benutzersicht Gespeichert
  4. 4. Speichern Benutzersicht Anbindung UI Architektursicht Anbindung Datenbank Fehlerbehandlung
  5. 5. Validator Datenvalidierung Benutzersicht Button Entwicklersicht Fehlerbehandlung Fehlerausschrift Datenbankanbindung Speichern Validierungsregeln Speichervorgang Zurücksetzen bei Fehler
  6. 6. Systemtests Unit-Tests Validator Datenvalidierung Benutzersicht Button Entwicklersicht Fehlerbehandlung Fehlerausschrift Datenbankanbindung Speichern Validierungsregeln Speichervorgang Zurücksetzen bei Fehler DS DB Extern
  7. 7. „Nichts ist so beständig wie die Veränderung.“ Bob Dylan
  8. 8. „Wer als einziges Werkzeug einen Hammer hat, sieht in jedem Problem einen Nagel.“ Paul Watzlawick
  9. 9. Manuelle Tests Systemtests Integrationstests UnitTests
  10. 10. Vertrauen Feedback Aufwand
  11. 11. Tue nur Dinge die einen Mehrwert bedeuten!
  12. 12. Tue nur Dinge die einen Mehrwert ??? bedeuten.
  13. 13. Tue nur Dinge die einen Feedback !!! bedeuten.
  14. 14. Implementierung Test Refaktorisierung
  15. 15. Die Regeln • • • • Schreibe nur Code, der verlangt wird. Entwickle schrittweise Deinen Code. Wähle möglichst kleine Schritte. Je allgemeingültiger der Code desto spezifischer der Test.
  16. 16. Implementierung Test Refaktorisierung
  17. 17. System-Tests Unit-Tests Validator Datenvalidierung Benutzersicht Button Entwicklersicht Fehlerbehandlung Fehlerausschrift Datenbankanbindung Speichern Validierungsregeln Speichervorgang Zurücksetzen bei Fehler DS DB Extern
  18. 18. Validator Datenvalidierung Entwicklersicht Fehlerbehandlung Fehlerausschrift Datenbankanbindung Button Validierungsregeln Speichervorgang Zurücksetzen bei Fehler
  19. 19. Qualität ist wichtiger als Quantität
  20. 20. Hump of Pain “New teams are often expected to adopt practices such as TDD and refactoring, which are difficult to learn. Without good coaching, plenty of time to master new skills, and string management support, they're easily discouraged.” Quelle: Agile Testing: A Practical Guide for Testers and Agile Teams
  21. 21. Pragmatisch Eher Test First als Test Driven Eher Komponententests als Unit-Tests Eher interaktionsbasierend als statusbasierend public void Push(int value) { Count++; content[Count] = value; } Klassisch Eher Test Driven als Test First Eher Unit-Tests als Komponententests Eher statusbasierend als interaktionsbasierend public void Push(int value) public void Push(int value) {{ public void Push(int value) { Count++;= value; content } } content[Count] = value; }
  22. 22. Systemtest Integrationstest Unit-Test Quelle: Succeeding with Agile, Mike Cohn
  23. 23. Implementierung Systemtest Test Refaktorisierung
  24. 24. System-Tests Unit-Tests Validator Datenvalidierung Benutzersicht Button Entwicklersicht Fehlerbehandlung Fehlerausschrift Datenbankanbindung Speichern Validierungsregeln Speichervorgang Zurücksetzen bei Fehler DS DB Extern
  25. 25. System-Test Speichern DB Benutzersicht Extern
  26. 26. System-Test Unit-Tests Speichern Button Datenbankanbindung Speichervorgang DB Zurücksetzen bei Fehler Benutzersicht Entwicklersicht Extern
  27. 27. Problem verstehen Grobdesign („Architektur“) Automatisierung • Build • Deployment • End-To-End Tests Produktinkrement Produkt Release
  28. 28. Inside-Out TDD Implementierung geschieht vor allem im BL. Anbindung externer Ressourcen nachträglich über System Tests. Outside-In TDD Interaktoren kommunizieren über Schnittstellen. Schnittstellen werden gemockt. Architektur wird über Spikes getrieben. UI UI BL BL DA DA
  29. 29. Inside-Out TDD Outside-In TDD Mehr statusbasierende Tests. Vor allem in „weniger“ agilen Teams zu finden. Mehr interaktionsbasierende Tests. Zwingt zu featurebasierender Implementierung. Mach global Code Ownership notwendig. UI UI BL BL DA DA
  30. 30. Gherkin Funktionalität: Nächster Arbeitsschritt nach der Bilderauswahl Damit die ausgewählten Bilder weiter verarbeitet werden können soll der nächste Arbeitsschritt in der Bilderauswahl immer erreichbar sein. Szenario: Nächster Arbeitsschritt aus der Bilderauswahl verfügbar Angenommen die Bilderauswahl ist geöffnet Wenn ein Bild ausgewählt wird Dann soll man zum nächsten Arbeitsschritt navigieren können
  31. 31. Gherkin Funktionalität: Nächster Arbeitsschritt nach der Bilderauswahl Damit die ausgewählten Bilder weiter verarbeitet werden können soll der nächste Arbeitsschritt in der Bilderauswahl immer erreichbar sein. Szenario: Nächster Arbeitsschritt aus der Bilderauswahl verfügbar Angenommen die Bilderauswahl ist geöffnet Wenn ein Bild ausgewählt wird Dann soll man zum nächsten Arbeitsschritt navigieren können Szenario: Navigieren nicht möglich wenn kein Bild ausgewählt ist Angenommen die Bilderauswahl ist geöffnet Wenn kein Bild ausgewählt wird Dann soll man nicht zum nächsten Arbeitsschritt navigieren können
  32. 32. Happy Path!!!
  33. 33. Quelle: Growing Object oriented Software guided by Tests
  34. 34. Vertrauen Feedback Aufwand
  35. 35. Hendrik Lösch Hendrik.Loesch@saxsys.de just-about.net @HerrLoesch
  36. 36. Transformation Priority Premise ({} → nil) (nil → constant) (constant → constant+) (constant → scalar) (statement → statements) (unconditional → if) (scalar → array) (array → container) (statement → recursion) (if → while) (expression → function) (variable → assignment) → Keinen Code in Code umwandeln, der nichts implementiert. → Einführen einer Konstanten. → Einfache Konstante in komplexere Konstante überführen. → Konstante durch Variable oder Argument ersetzen. → Anweisung durch zusätzliche Anweisungen erweitern. → Bedingungslose Codepfade in bedingte Codepfade ändern. → Zahlenwert in Array wandeln. → Array in eine Liste oder komplexeren Container überführen. → Anweisung rekursiv umsetzen. → Fallunterscheidungen in Schleifen ändern. → Ausdruck durch Funktion ersetzen. → Variablen mit Zuweisungen erweitern.
  37. 37. Fast Isolated Independent Repeatable Self-Verifying Timely
  38. 38. “ The SOLID principles are not rules. They are not laws. They are not perfect truths. They are statements on the order of “An apple a day keeps the doctor away.” ” Quelle: https://sites.google.com/site/unclebobconsultingllc/getting-a-solid-start Robert C. Martin (Uncle Bob)
  39. 39. S O L I D ingle Responsibility Principle pen Closed Principle iskov Substitution Principle nterface Segregation Principle ependency Inversion Principle
  40. 40. S O L I D ingle Responsibility Principle pen Closed Principle iskov Substitution Principle nterface Segregation Principle ependency Inversion Principle Quelle: http://www.clean-code-developer.de/ Eine Klasse sollte nur eine Verantwortlichkeit haben.
  41. 41. S O L I D ingle Responsibility Principle pen Closed Principle iskov Substitution Principle nterface Segregation Principle ependency Inversion Principle Quelle: http://www.clean-code-developer.de/ Eine Klasse sollte offen für Erweiterungen, jedoch geschlossen für Modifikationen sein.
  42. 42. S O L I D ingle Responsibility Principle pen Closed Principle iskov Substitution Principle nterface Segregation Principle ependency Inversion Principle Quelle: http://www.clean-code-developer.de/ Abgeleitete Klassen sollten sich so verhalten wie es von ihren Basistypen erwartet wird.
  43. 43. S O L I D ingle Responsibility Principle pen Closed Principle iskov Substitution Principle nterface Segregation Principle ependency Inversion Principle Quelle: http://www.clean-code-developer.de/ Interfaces sollten nur die Funktionalität wiederspiegeln die ihre Klienten erwarten.
  44. 44. S O L I D ingle Responsibility Principle pen Closed Principle iskov Substitution Principle nterface Segregation Principle ependency Inversion Principle Quelle: http://www.clean-code-developer.de/ High-Level Klassen sollen nicht von Low-Level Klassen abhängig sein, sondern beide von Interfaces. Interfaces sollen nicht von Details abhängig sein, sondern Details von Interfaces.

×