1
Agiles Testing Johannes Stiehler
Copyright: industrieblick - Fotolia
2
Test Driven
Development
Das Grundprinzip
Die Regeln
1. Du darfst keinerlei Produktionscode schreiben, bevor du
nicht einen scheiternden Unit-Test geschrieben hast....
Warum Test-First
• Der Test wird getestet (dadurch, dass er erstmal
scheitert).
• Der Test gibt das Interface vor, dadurch...
5
Vorteile
Sicherheit — der Code ist getestet
Mut — Änderungen brechen keine Funktionalität
Dokumentation — die Tests beschr...
Komplexe Funktionalität testen
7
Domänenmodell
Support Klassen
Service Interface
Anforderung
Outside-In
Inside-Out
Ebenen testgetriebener Entwicklung
• Code-Ebene mit Unit-Tests (whitebox)
• Applikationsebene mit System-Tests
• Produkteb...
Ergänzende Praktiken
• Clean Code
• Pair Programming
• Code Reviews
• Simple Design
• Kollektives Eigentum
9
Designprinzipen für das Refactoring
Dependency Inversion Principle (DIP)
Don't Repeat Yourself (DRY)
Favour Composition ov...
Designprinzipen für das Refactoring
Law of Demeter (LOD)
Liskov Substitution Principle (LSP)
Open Closed Principle (OCP)  ...
Designprinzipen für das Refactoring
Keep It Simple Stupid (KISS)
Separation of Concerns (SoC)
Single Responsibility Princi...
Wartbare Tests
13
Given – When – Then
Feature: User trades stocks

Scenario: User requests a sell before close of trading
Given I have 100 s...
Given
• Zustand der „Welt“ vor der zu testenden Aktion
• Setup, Parameter etc.
• Vorbedingungen (fail early)
• Vergangenhe...
When
• zu testende Aktion
• nur eine When-Aussage
• beschreibt den Zweck des Tests eindeutig
• Gegenwartsform
• Aktiv
16
Then
• erwartete Ergebnisse nach der Aktion
• nicht überspezifizieren
• Zukunftsform
• Passiv
• Werte, nicht Aktionen
17
Test-Benennung
• irgendwie (test1, test2, test3, test4)
• wie die Methode, die getestet wird
• wie das Verhalten das erwar...
Test-Data-Builder
Order order=anOrder() # factory method for builder
.fromCustomer( # builder method
aCustomer().withAddre...
Hamcrest
assertThat(instruments,
hasItem(instrumentWithPrice(greaterThan(81))
Expected: a collection containing instrument...
Wie entkoppelt man Frontend-Tests vom HTML?
Page Objects
public class LoginPage {
    public HomePage loginAs(String usern...
Long live the test
Test-Code sollte die gleiche – wenn nicht bessere –
Qualität haben wie Produktivcode, da er in einem
ag...
Tests für Legacy-Systeme
23
Schritt 1: System Tests
24
Schritt 1: Was testen?
• Risiko-basiertes Testen: Regression für die kritischsten
Komponenten, änderungsbasierte Tests für...
Schritt 2: Komponenten-Test
26
Schritt 3: Testbare Teile auslagern
• Methoden durch IDE-Refactorings extrahieren
• extrahierte Methoden in separate Klass...
Schritt 4: konsequentes TDD
• nach weitgehender Umarbeitung ganzer Komponenten
• Inkonsequenz lässt sofort wieder „Alt-Cod...
Vielen Dank für Ihre Aufmerksamkeit
johannes.stiehler@ideenpla.net
29
Nächste SlideShare
Wird geladen in …5
×

Agiles Testing

614 Aufrufe

Veröffentlicht am

Testen als Kern eines agilen Entwicklungsprozesses.
Kurze Erklärung wesentlicher Ansätze und Begriffe.

Veröffentlicht in: Software
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
614
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
12
Aktionen
Geteilt
0
Downloads
16
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Agiles Testing

  1. 1. 1 Agiles Testing Johannes Stiehler Copyright: industrieblick - Fotolia
  2. 2. 2 Test Driven Development Das Grundprinzip
  3. 3. Die Regeln 1. Du darfst keinerlei Produktionscode schreiben, bevor du nicht einen scheiternden Unit-Test geschrieben hast. 2. Du darfst nicht mehr von einem Unit-Test schreiben, als nötig ist, um zu scheitern – Nicht-Kompilieren ist Scheitern. 3. Du darfst nicht mehr Produktionscode schreiben, als notwendig ist, um den momentan scheiternden Unit-Test zu bestehen. 3
  4. 4. Warum Test-First • Der Test wird getestet (dadurch, dass er erstmal scheitert). • Der Test gibt das Interface vor, dadurch entstehen testbare Klassen. • Der Tests hilft, strukturiert über die Anforderungen nachzudenken. • Der Fokus liegt auf simplen, robusten Lösungen. 4
  5. 5. 5
  6. 6. Vorteile Sicherheit — der Code ist getestet Mut — Änderungen brechen keine Funktionalität Dokumentation — die Tests beschreiben das Verhalten Design — das einfachste Design, das funktioniert 6
  7. 7. Komplexe Funktionalität testen 7 Domänenmodell Support Klassen Service Interface Anforderung Outside-In Inside-Out
  8. 8. Ebenen testgetriebener Entwicklung • Code-Ebene mit Unit-Tests (whitebox) • Applikationsebene mit System-Tests • Produktebene mit Akzeptanz-Tests 8
  9. 9. Ergänzende Praktiken • Clean Code • Pair Programming • Code Reviews • Simple Design • Kollektives Eigentum 9
  10. 10. Designprinzipen für das Refactoring Dependency Inversion Principle (DIP) Don't Repeat Yourself (DRY) Favour Composition over Inheritance (FCoI) Information Hiding Principle (IHP) Interface Segregation Principle (ISP) 10
  11. 11. Designprinzipen für das Refactoring Law of Demeter (LOD) Liskov Substitution Principle (LSP) Open Closed Principle (OCP)       Principle of Least Astonishment (PoLA)       Single Level of Abstraction (SLA) 11
  12. 12. Designprinzipen für das Refactoring Keep It Simple Stupid (KISS) Separation of Concerns (SoC) Single Responsibility Principle (SRP) Tell don't ask (TDA) You ain't gonna need it (YAGNI)  12
  13. 13. Wartbare Tests 13
  14. 14. Given – When – Then Feature: User trades stocks
 Scenario: User requests a sell before close of trading Given I have 100 shares of MSFT stock
 And I have 150 shares of APPL stock
 And the time is before close of trading When I ask to sell 20 shares of MSFT stock Then I should have 80 shares of MSFT stock
 And I should have 150 shares of APPL stock
 And a sell order has been executed 14
  15. 15. Given • Zustand der „Welt“ vor der zu testenden Aktion • Setup, Parameter etc. • Vorbedingungen (fail early) • Vergangenheitsform • Passiv • Werte, nicht Aktionen 15
  16. 16. When • zu testende Aktion • nur eine When-Aussage • beschreibt den Zweck des Tests eindeutig • Gegenwartsform • Aktiv 16
  17. 17. Then • erwartete Ergebnisse nach der Aktion • nicht überspezifizieren • Zukunftsform • Passiv • Werte, nicht Aktionen 17
  18. 18. Test-Benennung • irgendwie (test1, test2, test3, test4) • wie die Methode, die getestet wird • wie das Verhalten das erwartet wird @Test
 public void holdsItemsInTheOrderTheyWereAdded() 18
  19. 19. Test-Data-Builder Order order=anOrder() # factory method for builder .fromCustomer( # builder method aCustomer().withAddress( # factory method anAddress().withPostcode())).build(); 19
  20. 20. Hamcrest assertThat(instruments, hasItem(instrumentWithPrice(greaterThan(81)) Expected: a collection containing instrument at price a value greater than <81> but: price was <50>, price was <72>, price was <31> 20
  21. 21. Wie entkoppelt man Frontend-Tests vom HTML? Page Objects public class LoginPage {     public HomePage loginAs(String username, String password) {         // ... clever magic happens here     }         public LoginPage loginAsExpectingError(String username, String password) {         //  ... failed login here, maybe because one or both of the username and 
 // password are wrong     }         public String getErrorMessage() {         // So we can verify that the correct error is shown     } } 21
  22. 22. Long live the test Test-Code sollte die gleiche – wenn nicht bessere – Qualität haben wie Produktivcode, da er in einem agilen Projekt vermutlich länger „überlebt“. 22
  23. 23. Tests für Legacy-Systeme 23
  24. 24. Schritt 1: System Tests 24
  25. 25. Schritt 1: Was testen? • Risiko-basiertes Testen: Regression für die kritischsten Komponenten, änderungsbasierte Tests für alle zukünftigen Features. • Äquivalenzpartitionierung: Nur Werte mit potentiell unterschiedlichem Verhalten werden getestet, beginnend mit den häufigsten Werbereichen. • Änderungsfrequenz: Was sich häufig ändert, wird zuerst getestet. 25
  26. 26. Schritt 2: Komponenten-Test 26
  27. 27. Schritt 3: Testbare Teile auslagern • Methoden durch IDE-Refactorings extrahieren • extrahierte Methoden in separate Klassen schieben • Unit-Tests für diese neuen Klassen schreiben • neue Features mit TDD hinzufügen 27
  28. 28. Schritt 4: konsequentes TDD • nach weitgehender Umarbeitung ganzer Komponenten • Inkonsequenz lässt sofort wieder „Alt-Code“ entstehen • ein fehlender Test ist technische Schuld • test-last-Entwicklung erzeugt technische Schuld 28
  29. 29. Vielen Dank für Ihre Aufmerksamkeit johannes.stiehler@ideenpla.net 29

×