UnitTests?Ja,aberrichtig!...RelativeKostenvonFehlern WieteueristeinFehlerinAbhängigkeitvomZeitpunktseinerEntdeckung: währendderEntwicklung 1 WennderEntwicklerdasfertigeFeaturetestet

überraschend mehr Möglichkeiten!

© OPITZ CONSULTING 2017

UnitTests? Ja, aber richtig!

O.O.P. Conference / München

Thomas Papendieck,Senior–Consultant

Inhalte

1 Worüber ich nicht spreche

2 Anforderungen an UnitTests

3 Anforderungen an zu testenden Code

4 UnitTest in Java

5 Hands on

© OPITZ CONSULTING 2017 UnitTests? Ja, aber richtig! 2 / 32

Worüber ich nicht spreche1.1 Vorteile von Unittetst

1.2 Probleme manueller Tests

1.3 Welche Tests sollten automatisiertwerden?

1


Relative Kosten von Fehlern

Wie teuer ist ein Fehler in Abhängigkeit vom Zeitpunkt seiner Entdeckung:

während der Entwicklung 1Wenn der Entwickler das fertige Feature testet 3Während der Integration 10Beim Abnahmetest 100in der Produktion 1000


Nachteile manueller Tests.

Software muss in einem Lauffähigen Zustand sein.

Tester benötigt wissen über die Anwendung.Was ist das gewünschte Verhalten?Was ist ein Fehler?

Wie testen man Fehlerzustände?

manuelle Tests sind langsam.

finden nur zu regulären Arbeitszeiten statt.

Testen ist langweilig.


Test Level

� Application Test

� rejection check formaly known as acceptance test.� performance/stress test

� Module Test

� Unit Test


Unterschied Application/Module–Tests zu UnitTests

Applications und Module Test

� werden spät im Entwicklungsprozess ausgeführt

� Testwerkzeuge sind komplex

� sind aufwendig zu warten

� zeigen, das ein Fehler existiert, aber nicht wo

UnitTest

� laufen früh im Entwicklungsprozess (idealer Weise nach jedem Speichern)

� Werkzeuge haben einfache API

� sind stabil gegen Änderungen (anderer Units)

� zeigen welche Anforderung nicht erfüllt wird, wo der Fehler existiert und unter welchenBedingungen er auftritt.

hoher UnitTest Abdeckung→ weniger Test höherer EbenenUnitTests prüfen die Geschäftslogik, Application/Module–Tests die ”Verdrahtung”


Warum schreiben wir keine automatisierten Tests?


was ist Test Driven Developement?

1. neuer Test

2. Transformation

3. Refactoring

1. Schreibe einen neuen Test, gerade so viel dass erfehl schlägt(nicht kompilieren ist fehlschlagen).

2. Schreibe gerade so viel Produktivcode, dass derTest erfüllt wird. Zukünftige Anforderungen nichtbeachten! (so simpel wie möglich, alles ist erlaubt,Transitions-Prämissen beachten).

3. Verbessere den Code (Produktion und Test), ohneeinen Test zu berchen und ohne neue Funktinalität(Geschäftslogik) hinzuzufügen.


persönliche, technische und soziale Voraussetzungen

� UnitTests schreiben ist eine Fertigkeit und muss ständig geübt werden.

� Technische Voraussetzungen müssen sichergestellt sein.

� Team und Vorgesetzte müssen automatisiertes Testen unterstützen.


Anforderungen an UnitTests

2


Was ist ein guter UnitTest?

� Readable - lesbar

� Trustworthy - vertrauenswürdig

� Fast - schnell

� Maintainable - wartbar


Was bedeutet lesbar?

� was wird getestetName des Tests drückt vorbedingungen und erwartetes ergebnis aus.

� kurzwiederkehrende Vorbereitungen in methoden auslagern

� Welche Eigenschaften der Parameter sind wichtig?Explizit Variablen für Parameterwerte anlegen

Variablennamen sorgsam wählen

� Welche Eigenschaften der Ergebnisse sind wichtig?Explizit Variablen für Ergebnisse anlegenVariablennamen sorgsam wählen

Verifizierungsmethoden mit sprechenden Namen.


Beispiel Lesbarkeit


Was bedeutet vertrauenswürdig?

� Geschäftsanforderungen erfülltWurde tatsächlich implementiert, was der Kunde wollte?

� technischWird der Produktivcode tatsächlich ausgeführt?

Schlägt der Test aus dem richtigen Grund fehl?

� Ersetzten von Abhängigkeiten (Mocking)� ”test first”� (weitestgehend) keine Logik in Tests


Was bedeutet schnell?

� Tests sollen sehr häufig ausgeführt werden (wo möglich nach jedemSpeichern). Dadurch erhalten wir sofort Feedback, ob die letzte Änderungeinen Fehler verursacht hat.

� Aufwendige und potenziell langsame Logik in Abhängigkeiten der Unitmüssen ersetzt werden.


Was bedeutet wartbar?

� Stabilität gegenüber Änderungen in anderen UnitsAbhängigkeiten ersetzen

� stabil gegen Änderungen in der Unit selbsteine einzelne Anforderung (nicht Codestelle) testen.


Anforderungen an zu testenden Code3.1 Was verbessert die Testbarkeit?

3.2 Isolieren einer Unit

3.3 Isolation Ermöglichen

3


Testbarkeit von produktivem Code

Qualität des produktivem Code (im sinne von ”Clean Code”) beeinflußt dieQualität der Tests (im Sinne der RTFM– Anforderungen)

die wichtigsten ”Clean Code” Regeln sind:

� Separation of concerns

� single resposibilityErzeugung von Objekten der Abhängigkeiten ist keine Aufgabe der Geschäftslogik!

� Tell! Don’t ask.

� Law of Demeter (Don’t talk to strangers)vermeide ”message chaining” (nicht mit ”fluent API” verwechseln)


Testbarkeit von produktivem Code


Arten von Test–Doubles

� Stub

� leere Implementierung einer Schnittstelle, üblicher Weise generiert

� Fake

� alternative Implementierung einer Schnittstelle oder Erweiterung einerexistierenden Implementierung.

� extrem vereinfachtes Verhalten (keine Logik)

� Mock

� ”aufgemotztes” Fake� konfigurierbares Verhalten� Verifizierung vom Methodenaufrufen und der übergebenen Parameter


Was Ermöglicht die Ersetzung von Abhängigkeiten?

� trenne Instanziierung der Abhängigkeiten von der Geschäftslogik

� vermeide den Aufruf des new Operators

� Bereitstellen von ”seams” (Nahtstellen)

� dependency injection� Getter mit geringer Sichtbarkeit

� keine static (public) Methoden

� keine final (public) Methoden

� vermeide Singelton Pattern (nicht Singelton als Konzept)


schreibe ”Clean Code”1

� programmiere gegen Schnittstellen

� SoC/SRP (Feature envy)

� Law of Demeter

� DRY

� same level of abstraction

1”Clean Code” by Robert C Martin, ISBN-13: 978-0132350884


UnitTest in Java4.1 Werkzeuge

4.2 Code Vorlagen

4.3 Transformationsprämissen

4


Starterkit für Java Entwickler

� IDE including testplugin (eclipse + infinitest / Netbeans + ? /...)

� build – tool (maven / gradle / ant / ...)

� SCM (git / subversion / ...)

� xUnit testing framework (JUnit / NUnit /...)

� mocking framwork (Mockito / ...)


einen JUnit Test schreiben

1 class PlainOldJavaClass {23 @Test / / marks a method so that i t s been ca l led by JUn i t4 public / / tes t methods must be publ ic5 void / / tes t methods must not return anything6 calculate_worstGame_returnsZero ( ) / / no parameters7 {8 / / arrange : create and configure dependencies and var iab les9 String playerResul tA l lZero = ” 0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ” ;

10 int expectedResult = 0 ;1112 / / act : create tested unit ( i f possible ) and c a l l tested method .13 int ca lcu latedResul t = new BowlingCalculator ( ) . ca l cu la te ( p layerResul tA l lZero ) ;1415 / / assert : check the Result by ca l l i n g one of JUn i ts assert methods .16 / / the assert method throws an exception when the check f a i l s .17 assertEquals ( ” a l l ␣zeros␣ in ” , / / g ive use fu l l short ( ! ) addi t iona l descr ipt ion18 / / skip when in doubt19 expectedResult ,20 ca lcu latedResul t ) ;21 }22 }


Mockito verwenden

1 class PlainOldJavaClass {2 @Test3 public void testedMethod__preconditions__expectedBehavior ( ) {4 / / create mock5 MyInterfaceOrClass mockObject = mock( MyInterfaceOrClass . class ) ;6 / / create a spy7 MyClass spyObject = spy (new MyClass ( ) ) ;8 / / configure behavior :9 doThrow (new RuntimeException ( ” simulate␣error ” ) )

10 .when ( mockObject ) . anyMethod ( ) ;11 doReturn (mockObject , null , mockObject )12 . thenThrow (new RuntimeException ( ” simulate␣error␣af ter ␣4th␣ c a l l ” ) )13 .when ( spyObject ) . methodWithReturnValue ( ) ;1415 / / a l te rna t i ve for non void methods :16 .when ( spyObject . methodWithReturnValue ( ) )17 . thenReturn (mockObject , null , mockObject )18 . thenThrow (new RuntimeException ( ” simulate␣error␣af ter ␣4th␣ c a l l ” ) ) ;1920 / / check c a l l of method21 ve r i f y ( spyObject ) . expectedMethodCall ( mockObject , any ( OtherInterfaceOrClass . class ) ) ;22 }23 }


Test Driven Developement

1. neuer Test

2. Transformation

3. Refactoring

1. Schreibe einen neuen Test, gerade so viel dass erfehl schlägt(nicht kompilieren ist fehlschlagen).

2. Schreibe gerade so viel Produktivcode, dass derTest erfüllt wird. Zukünftige Anforderungen nichtbeachten! (so simpel wie möglich, alles ist erlaubt,Transitions-Prämissen beachten).

3. Verbessere den Code (Produktion und Test), ohneeinen Test zu berchen und ohne neue Funktinalität(Geschäftslogik) hinzuzufügen.


Transformationsprämissen1

In der Implementierungsphase des TDD–Zyklus ist im Fall, dass mehrereTransitionen möglich sind, die jenige anzuwenden, die in der folgenden Listeam weitesten oben steht:

1. constant a value

2. scalar a local binding, or variable

3. invocation calling a function/method

4. conditional if/switch/case/cond

5. while loop applies to for loops as well

6. assignment replacing the value of a variable

1”Transformation Priority Premise Applied” by Micah Martin, https://8thlight.com/blog/micah-martin/2012/11/17/transformation-priority-premise-applied.html


https://8thlight.com/blog/micah-martin/2012/11/17/transformation-priority-premise-applied.html

https://8thlight.com/blog/micah-martin/2012/11/17/transformation-priority-premise-applied.html

Hands on

5


KataBowling

http://codingdojo.org/cgi-bin/index.pl?KataBowling


http://codingdojo.org/cgi-bin/index.pl?KataBowling

überraschend mehr Möglichkeiten!

© OPITZ CONSULTING 2017

Vielen Dank für die Aufmerksamkeit.

Thomas Papendieck

Senior–Consultant

Norsk–Data–Straße 461348 Bad Homburg

[email protected]+49 6172 66260 1523


[email protected]

Documents

UnitTests?Ja,aberrichtig!...RelativeKostenvonFehlern WieteueristeinFehlerinAbhängigkeitvomZeitpunktseinerEntdeckung: währendderEntwicklung 1 WennderEntwicklerdasfertigeFeaturetestet