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. 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
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
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. 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. 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
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. Given
• Zustand der „Welt“ vor der zu testenden Aktion
• Setup, Parameter etc.
• Vorbedingungen (fail early)
• Vergangenheitsform
• Passiv
• Werte, nicht Aktionen
15
16. When
• zu testende Aktion
• nur eine When-Aussage
• beschreibt den Zweck des Tests eindeutig
• Gegenwartsform
• Aktiv
16
17. Then
• erwartete Ergebnisse nach der Aktion
• nicht überspezifizieren
• Zukunftsform
• Passiv
• Werte, nicht Aktionen
17
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. Test-Data-Builder
Order order=anOrder() # factory method for builder
.fromCustomer( # builder method
aCustomer().withAddress( # factory method
anAddress().withPostcode())).build();
19
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. 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
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
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. 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. Vielen Dank für Ihre Aufmerksamkeit
johannes.stiehler@ideenpla.net
29