Das Dokument beschreibt die Prinzipien des Test Driven Development (TDD) und die Vorteile von testfirst-Ansätzen, einschließlich der Entwicklung testbarer Klassen und der Fokussierung auf einfache, robuste Lösungen. Es werden verschiedene Designprinzipien für das Refactoring sowie ergänzende Praktiken wie Clean Code und Pair Programming vorgestellt. Zudem wird auf die Wichtigkeit von wartbaren Tests und der Umsetzung von Tests in Legacy-Systemen eingegangen.

1. 1
Agiles Testing Johannes Stiehler
Copyright: industrieblick - Fotolia

2. 2
Test Driven
Development
Das Grundprinzip

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

5. 5

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. Komplexe Funktionalität testen
7
Domänenmodell
Support Klassen
Service Interface
Anforderung
Outside-In
Inside-Out

8. Ebenen testgetriebener Entwicklung
• Code-Ebene mit Unit-Tests (whitebox)
• Applikationsebene mit System-Tests
• Produktebene mit Akzeptanz-Tests
8

9. Ergänzende Praktiken
• Clean Code
• Pair Programming
• Code Reviews
• Simple Design
• Kollektives Eigentum
9

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

13. Wartbare Tests
13

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

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. 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

23. Tests für Legacy-Systeme
23

24. Schritt 1: System Tests
24

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. Schritt 2: Komponenten-Test
26

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