29
1 Agiles Testing Johannes Stiehler Copyright: industrieblick - Fotolia

Agiles Testing

Embed Size (px)

Citation preview

Page 1: Agiles Testing

1

Agiles Testing Johannes Stiehler

Copyright: industrieblick - Fotolia

Page 2: Agiles Testing

2

Test Driven Development

Das Grundprinzip

Page 3: Agiles Testing

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

Page 4: Agiles Testing

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

Page 5: Agiles Testing

5

Page 6: Agiles Testing

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

Page 7: Agiles Testing

Komplexe Funktionalität testen7

Domänenmodell

Support Klassen

Service Interface

Anforderung

Outside-In

Insid

e-O

ut

Page 8: Agiles Testing

Ebenen testgetriebener Entwicklung

• Code-Ebene mit Unit-Tests (whitebox)

• Applikationsebene mit System-Tests

• Produktebene mit Akzeptanz-Tests

8

Page 9: Agiles Testing

Ergänzende Praktiken

• Clean Code

• Pair Programming

• Code Reviews

• Simple Design

• Kollektives Eigentum

9

Page 10: Agiles Testing

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

Page 11: Agiles Testing

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

Page 12: Agiles Testing

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

Page 13: Agiles Testing

Wartbare Tests

13

Page 14: Agiles Testing

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

Page 15: Agiles Testing

Given

• Zustand der „Welt“ vor der zu testenden Aktion

• Setup, Parameter etc.

• Vorbedingungen (fail early)

• Vergangenheitsform

• Passiv

• Werte, nicht Aktionen

15

Page 16: Agiles Testing

When

• zu testende Aktion

• nur eine When-Aussage

• beschreibt den Zweck des Tests eindeutig

• Gegenwartsform

• Aktiv

16

Page 17: Agiles Testing

Then

• erwartete Ergebnisse nach der Aktion

• nicht überspezifizieren

• Zukunftsform

• Passiv

• Werte, nicht Aktionen

17

Page 18: Agiles Testing

Test-Benennung

• irgendwie (test1, test2, test3, test4)

• wie die Methode, die getestet wird

• wie das Verhalten das erwartet wird

@Testpublic void holdsItemsInTheOrderTheyWereAdded()

18

Page 19: Agiles Testing

Test-Data-Builder

Order order=anOrder() # factory method for builder

.fromCustomer( # builder method

aCustomer().withAddress( # factory method

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

19

Page 20: Agiles Testing

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

Page 21: Agiles Testing

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

Page 22: Agiles Testing

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

Page 23: Agiles Testing

Tests für Legacy-Systeme

23

Page 24: Agiles Testing

Schritt 1: System Tests24

Page 25: Agiles Testing

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

Page 26: Agiles Testing

Schritt 2: Komponenten-Test26

Page 27: Agiles Testing

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

Page 28: Agiles Testing

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

Page 29: Agiles Testing

Vielen Dank für Ihre Aufmerksamkeit

[email protected]

29