Agiles Testing

Click here to load reader

  • date post

    17-Jul-2015
  • Category

    Software

  • view

    228
  • download

    2

Embed Size (px)

Transcript of Agiles Testing

  • 1Agiles Testing Johannes Stiehler

    Copyright: industrieblick - Fotolia

  • 2Test 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 ntig 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 Lsungen.

    4

  • 5

  • Vorteile

    Sicherheit der Code ist getestet

    Mut nderungen brechen keine Funktionalitt

    Dokumentation die Tests beschreiben das Verhalten

    Design das einfachste Design, das funktioniert

    6

  • Komplexe Funktionalitt testen7

    Domnenmodell

    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

  • Ergnzende Praktiken

    Clean Code

    Pair Programming

    Code Reviews

    Simple Design

    Kollektives Eigentum

    9

  • Designprinzipen fr 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 fr 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 fr 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 stocksScenario: 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 stockAnd 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

    but: price was , price was , price was

    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 Qualitt haben wie Produktivcode, da er in einem

    agilen Projekt vermutlich lnger berlebt.

    22

  • Tests fr Legacy-Systeme

    23

  • Schritt 1: System Tests24

  • Schritt 1: Was testen?

    Risiko-basiertes Testen: Regression fr die kritischsten Komponenten, nderungsbasierte Tests fr alle zuknftigen Features.

    quivalenzpartitionierung: Nur Werte mit potentiell unterschiedlichem Verhalten werden getestet, beginnend mit den hufigsten Werbereichen.

    nderungsfrequenz: Was sich hufig 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 fr diese neuen Klassen schreiben

    neue Features mit TDD hinzufgen

    27

  • Schritt 4: konsequentes TDD

    nach weitgehender Umarbeitung ganzer Komponenten

    Inkonsequenz lsst sofort wieder Alt-Code entstehen

    ein fehlender Test ist technische Schuld

    test-last-Entwicklung erzeugt technische Schuld

    28

  • Vielen Dank fr Ihre Aufmerksamkeit

    [email protected]

    29