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.

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

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

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

Komplexe Funktionalität testen7

Domänenmodell

Support Klassen

Service Interface

Anforderung

Outside-In

Insid

e-O

ut

Ebenen testgetriebener Entwicklung

• Code-Ebene mit Unit-Tests (whitebox)

• Applikationsebene mit System-Tests

• Produktebene mit Akzeptanz-Tests

8

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 over Inheritance (FCoI)

Information Hiding Principle (IHP)

Interface Segregation Principle (ISP)

10

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

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

Wartbare Tests

13

Given – When – Then

Feature: User trades stocks Scenario: User requests a sell before close of trading

Given I have 100 shares of MSFT stockAnd I have 150 shares of APPL stockAnd 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

Given

• Zustand der „Welt“ vor der zu testenden Aktion

• Setup, Parameter etc.

• Vorbedingungen (fail early)

• Vergangenheitsform

• Passiv

• Werte, nicht Aktionen

15

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 erwartet wird

@Testpublic void holdsItemsInTheOrderTheyWereAdded()

18

Test-Data-Builder

Order order=anOrder() # factory method for builder

.fromCustomer( # builder method

aCustomer().withAddress( # factory method

anAddress().withPostcode())).build();

19

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

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

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

Tests für Legacy-Systeme

23

Schritt 1: System Tests24

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

Schritt 2: Komponenten-Test26

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

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

Vielen Dank für Ihre Aufmerksamkeit

johannes.stiehler@ideenpla.net

29