überraschend mehr Möglichkeiten!
© OPITZ CONSULTING 2017
UnitTests? Ja, aber richtig!
O.O.P. Conference / München
Thomas P...
Inhalte
1 Worüber ich nicht spreche
2 Anforderungen an UnitTests
3 Anforderungen an zu testenden Code
4 UnitTest in Java
5...
Worüber ich nicht spreche
1.1 Vorteile von Unittetst
1.2 Probleme manueller Tests
1.3 Welche Tests sollten automatisiert
w...
Relative Kosten von Fehlern
Wie teuer ist ein Fehler in Abhängigkeit vom Zeitpunkt seiner Entdeckung:
während der Entwickl...
Nachteile manueller Tests.
Software muss in einem Lauffähigen Zustand sein.
Tester benötigt wissen über die Anwendung.
Was...
Test Level
Application Test
rejection check formaly known as acceptance test.
performance/stress test
Module Test
Unit Tes...
Unterschied Application/Module–Tests zu UnitTests
Applications und Module Test
werden spät im Entwicklungsprozess ausgefüh...
Warum schreiben wir keine automatisierten Tests?
© OPITZ CONSULTING 2017 UnitTests? Ja, aber richtig! 8 / 32
was ist Test Driven Developement?
1. neuer Test
2. Transformation
3. Refactoring
1. Schreibe einen neuen Test, gerade so v...
persönliche, technische und soziale Voraussetzungen
UnitTests schreiben ist eine Fertigkeit und muss ständig geübt werden....
Anforderungen an UnitTests
2
© OPITZ CONSULTING 2017 UnitTests? Ja, aber richtig! 11 / 32
Was ist ein guter UnitTest?
Readable - lesbar
Trustworthy - vertrauenswürdig
Fast - schnell
Maintainable - wartbar
© OPITZ...
Was bedeutet lesbar?
was wird getestet
Name des Tests drückt vorbedingungen und erwartetes ergebnis aus.
kurz
wiederkehren...
Beispiel Lesbarkeit
© OPITZ CONSULTING 2017 UnitTests? Ja, aber richtig! 14 / 32
Was bedeutet vertrauenswürdig?
Geschäftsanforderungen erfüllt
Wurde tatsächlich implementiert, was der Kunde wollte?
techn...
Was bedeutet schnell?
Tests sollen sehr häufig ausgeführt werden (wo möglich nach jedem
Speichern). Dadurch erhalten wir so...
Was bedeutet wartbar?
Stabilität gegenüber Änderungen in anderen Units
Abhängigkeiten ersetzen
stabil gegen Änderungen in ...
Anforderungen an zu testenden Code
3.1 Was verbessert die Testbarkeit?
3.2 Isolieren einer Unit
3.3 Isolation Ermöglichen
...
Testbarkeit von produktivem Code
Qualität des produktivem Code (im sinne von ”Clean Code”) beeinflußt die
Qualität der Test...
Testbarkeit von produktivem Code
© OPITZ CONSULTING 2017 UnitTests? Ja, aber richtig! 20 / 32
Arten von Test–Doubles
Stub
leere Implementierung einer Schnittstelle, üblicher Weise generiert
Fake
alternative Implement...
Was Ermöglicht die Ersetzung von Abhängigkeiten?
trenne Instanziierung der Abhängigkeiten von der Geschäftslogik
vermeide ...
schreibe ”Clean Code”1
programmiere gegen Schnittstellen
SoC/SRP (Feature envy)
Law of Demeter
DRY
same level of abstracti...
UnitTest in Java
4.1 Werkzeuge
4.2 Code Vorlagen
4.3 Transformationsprämissen
4
© OPITZ CONSULTING 2017 UnitTests? Ja, abe...
Starterkit für Java Entwickler
IDE including testplugin (eclipse + infinitest / Netbeans + ? /...)
build – tool (maven / gr...
einen JUnit Test schreiben
1 class PlainOldJavaClass {
2
3 @Test / / marks a method so that i t s been called by JUnit
4 p...
Mockito verwenden
1 class PlainOldJavaClass {
2 @Test
3 public void testedMethod__preconditions__expectedBehavior ( ) {
4 ...
Test Driven Developement
1. neuer Test
2. Transformation
3. Refactoring
1. Schreibe einen neuen Test, gerade so viel dass ...
Transformationsprämissen1
In der Implementierungsphase des TDD–Zyklus ist im Fall, dass mehrere
Transitionen möglich sind,...
Hands on
5
© OPITZ CONSULTING 2017 UnitTests? Ja, aber richtig! 30 / 32
KataBowling
http://codingdojo.org/cgi-bin/index.pl?KataBowling
© OPITZ CONSULTING 2017 UnitTests? Ja, aber richtig! 31 / 32
überraschend mehr Möglichkeiten!
© OPITZ CONSULTING 2017
Vielen Dank für die Aufmerksamkeit.
Thomas Papendieck
Senior–Cons...
Nächste SlideShare
Wird geladen in …5
×

UnitTests? Ja, aber richtig!

119 Aufrufe

Veröffentlicht am

http://www.opitz-consulting.com

Oft erweisen sich Unittests gerade dann als problematisch, wenn bestehender Code geändert werden soll. Kleine Änderungen am produktiven Code erfordern nicht selten wesentlich umfangreichere Änderungen in den Unittests.

In diesem Vortrag mit anschließendem LiveCoding bei der OOP 2017 in München erklärte unser Experte Thomas Papendieck, warum solche Probleme entstehen und wie man sie vermeidet.

UnitTests sind ein wichtiger Bestandteil bei der Qualitätssicherung. Sie können ihre Vorteile aber nur dann voll entfalten, wenn sie die Weiterentwicklung des produktiven Codes nicht behindern.

Die Präsentation zeigt den Zusammenhang zwischen Code-Architektur, Testbarkeit und Qualität der Unittests und wie "CleanCode" sowie der Einsatz von Mocking-Frameworks zu besseren Unittests (und besserem Code) führen.

Veröffentlicht in: Technologie
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
119
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
1
Aktionen
Geteilt
0
Downloads
2
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

UnitTests? Ja, aber richtig!

  1. 1. überraschend mehr Möglichkeiten! © OPITZ CONSULTING 2017 UnitTests? Ja, aber richtig! O.O.P. Conference / München Thomas Papendieck, Senior–Consultant
  2. 2. 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
  3. 3. Worüber ich nicht spreche 1.1 Vorteile von Unittetst 1.2 Probleme manueller Tests 1.3 Welche Tests sollten automatisiert werden? 1 © OPITZ CONSULTING 2017 UnitTests? Ja, aber richtig! 3 / 32
  4. 4. Relative Kosten von Fehlern Wie teuer ist ein Fehler in Abhängigkeit vom Zeitpunkt seiner Entdeckung: während der Entwicklung 1 Wenn der Entwickler das fertige Feature testet 3 Während der Integration 10 Beim Abnahmetest 100 in der Produktion 1000 © OPITZ CONSULTING 2017 UnitTests? Ja, aber richtig! 4 / 32
  5. 5. 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. © OPITZ CONSULTING 2017 UnitTests? Ja, aber richtig! 5 / 32
  6. 6. Test Level Application Test rejection check formaly known as acceptance test. performance/stress test Module Test Unit Test © OPITZ CONSULTING 2017 UnitTests? Ja, aber richtig! 6 / 32
  7. 7. 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 welchen Bedingungen er auftritt. hoher UnitTest Abdeckung → weniger Test höherer Ebenen UnitTests prüfen die Geschäftslogik, Application/Module–Tests die ”Verdrahtung” © OPITZ CONSULTING 2017 UnitTests? Ja, aber richtig! 7 / 32
  8. 8. Warum schreiben wir keine automatisierten Tests? © OPITZ CONSULTING 2017 UnitTests? Ja, aber richtig! 8 / 32
  9. 9. was ist Test Driven Developement? 1. neuer Test 2. Transformation 3. Refactoring 1. Schreibe einen neuen Test, gerade so viel dass er fehl schlägt (nicht kompilieren ist fehlschlagen). 2. Schreibe gerade so viel Produktivcode, dass der Test erfüllt wird. Zukünftige Anforderungen nicht beachten! (so simpel wie möglich, alles ist erlaubt, Transitions-Prämissen beachten). 3. Verbessere den Code (Produktion und Test), ohne einen Test zu berchen und ohne neue Funktinalität (Geschäftslogik) hinzuzufügen. © OPITZ CONSULTING 2017 UnitTests? Ja, aber richtig! 9 / 32
  10. 10. 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. © OPITZ CONSULTING 2017 UnitTests? Ja, aber richtig! 10 / 32
  11. 11. Anforderungen an UnitTests 2 © OPITZ CONSULTING 2017 UnitTests? Ja, aber richtig! 11 / 32
  12. 12. Was ist ein guter UnitTest? Readable - lesbar Trustworthy - vertrauenswürdig Fast - schnell Maintainable - wartbar © OPITZ CONSULTING 2017 UnitTests? Ja, aber richtig! 12 / 32
  13. 13. Was bedeutet lesbar? was wird getestet Name des Tests drückt vorbedingungen und erwartetes ergebnis aus. kurz wiederkehrende 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 anlegen Variablennamen sorgsam wählen Verifizierungsmethoden mit sprechenden Namen. © OPITZ CONSULTING 2017 UnitTests? Ja, aber richtig! 13 / 32
  14. 14. Beispiel Lesbarkeit © OPITZ CONSULTING 2017 UnitTests? Ja, aber richtig! 14 / 32
  15. 15. Was bedeutet vertrauenswürdig? Geschäftsanforderungen erfüllt Wurde tatsächlich implementiert, was der Kunde wollte? technisch Wird 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 © OPITZ CONSULTING 2017 UnitTests? Ja, aber richtig! 15 / 32
  16. 16. Was bedeutet schnell? Tests sollen sehr häufig ausgeführt werden (wo möglich nach jedem Speichern). Dadurch erhalten wir sofort Feedback, ob die letzte Änderung einen Fehler verursacht hat. Aufwendige und potenziell langsame Logik in Abhängigkeiten der Unit müssen ersetzt werden. © OPITZ CONSULTING 2017 UnitTests? Ja, aber richtig! 16 / 32
  17. 17. Was bedeutet wartbar? Stabilität gegenüber Änderungen in anderen Units Abhängigkeiten ersetzen stabil gegen Änderungen in der Unit selbst eine einzelne Anforderung (nicht Codestelle) testen. © OPITZ CONSULTING 2017 UnitTests? Ja, aber richtig! 17 / 32
  18. 18. Anforderungen an zu testenden Code 3.1 Was verbessert die Testbarkeit? 3.2 Isolieren einer Unit 3.3 Isolation Ermöglichen 3 © OPITZ CONSULTING 2017 UnitTests? Ja, aber richtig! 18 / 32
  19. 19. Testbarkeit von produktivem Code Qualität des produktivem Code (im sinne von ”Clean Code”) beeinflußt die Qualität der Tests (im Sinne der RTFM– Anforderungen) die wichtigsten ”Clean Code” Regeln sind: Separation of concerns single resposibility Erzeugung 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) © OPITZ CONSULTING 2017 UnitTests? Ja, aber richtig! 19 / 32
  20. 20. Testbarkeit von produktivem Code © OPITZ CONSULTING 2017 UnitTests? Ja, aber richtig! 20 / 32
  21. 21. Arten von Test–Doubles Stub leere Implementierung einer Schnittstelle, üblicher Weise generiert Fake alternative Implementierung einer Schnittstelle oder Erweiterung einer existierenden Implementierung. extrem vereinfachtes Verhalten (keine Logik) Mock ”aufgemotztes” Fake konfigurierbares Verhalten Verifizierung vom Methodenaufrufen und der übergebenen Parameter © OPITZ CONSULTING 2017 UnitTests? Ja, aber richtig! 21 / 32
  22. 22. 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) © OPITZ CONSULTING 2017 UnitTests? Ja, aber richtig! 22 / 32
  23. 23. 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 © OPITZ CONSULTING 2017 UnitTests? Ja, aber richtig! 23 / 32
  24. 24. UnitTest in Java 4.1 Werkzeuge 4.2 Code Vorlagen 4.3 Transformationsprämissen 4 © OPITZ CONSULTING 2017 UnitTests? Ja, aber richtig! 24 / 32
  25. 25. 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 / ...) © OPITZ CONSULTING 2017 UnitTests? Ja, aber richtig! 25 / 32
  26. 26. einen JUnit Test schreiben 1 class PlainOldJavaClass { 2 3 @Test / / marks a method so that i t s been called by JUnit 4 public / / test methods must be public 5 void / / test methods must not return anything 6 calculate_worstGame_returnsZero ( ) / / no parameters 7 { 8 / / arrange : create and configure dependencies and variables 9 String playerResultAllZero = ” 0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ” ; 10 int expectedResult = 0; 11 12 / / act : create tested unit ( i f possible ) and c a l l tested method . 13 int calculatedResult = new BowlingCalculator ( ) . calculate ( playerResultAllZero ) ; 14 15 / / assert : check the Result by c a l l i n g one of JUnits assert methods . 16 / / the assert method throws an exception when the check f a i l s . 17 assertEquals ( ” a l l ␣zeros␣in ” , / / give usefull short ( ! ) additional description 18 / / skip when in doubt 19 expectedResult , 20 calculatedResult ) ; 21 } 22 } © OPITZ CONSULTING 2017 UnitTests? Ja, aber richtig! 26 / 32
  27. 27. Mockito verwenden 1 class PlainOldJavaClass { 2 @Test 3 public void testedMethod__preconditions__expectedBehavior ( ) { 4 / / create mock 5 MyInterfaceOrClass mockObject = mock( MyInterfaceOrClass . class ) ; 6 / / create a spy 7 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␣ after ␣4th␣ c a l l ” ) ) 13 .when ( spyObject ) . methodWithReturnValue ( ) ; 14 15 / / alternative for non void methods : 16 .when ( spyObject . methodWithReturnValue ( ) ) 17 . thenReturn ( mockObject , null , mockObject ) 18 . thenThrow (new RuntimeException ( ” simulate␣error␣ after ␣4th␣ c a l l ” ) ) ; 19 20 / / check c a l l of method 21 verify ( spyObject ) . expectedMethodCall ( mockObject , any ( OtherInterfaceOrClass . class ) ) ; 22 } 23 } © OPITZ CONSULTING 2017 UnitTests? Ja, aber richtig! 27 / 32
  28. 28. Test Driven Developement 1. neuer Test 2. Transformation 3. Refactoring 1. Schreibe einen neuen Test, gerade so viel dass er fehl schlägt (nicht kompilieren ist fehlschlagen). 2. Schreibe gerade so viel Produktivcode, dass der Test erfüllt wird. Zukünftige Anforderungen nicht beachten! (so simpel wie möglich, alles ist erlaubt, Transitions-Prämissen beachten). 3. Verbessere den Code (Produktion und Test), ohne einen Test zu berchen und ohne neue Funktinalität (Geschäftslogik) hinzuzufügen. © OPITZ CONSULTING 2017 UnitTests? Ja, aber richtig! 28 / 32
  29. 29. Transformationsprämissen1 In der Implementierungsphase des TDD–Zyklus ist im Fall, dass mehrere Transitionen möglich sind, die jenige anzuwenden, die in der folgenden Liste am 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 © OPITZ CONSULTING 2017 UnitTests? Ja, aber richtig! 29 / 32
  30. 30. Hands on 5 © OPITZ CONSULTING 2017 UnitTests? Ja, aber richtig! 30 / 32
  31. 31. KataBowling http://codingdojo.org/cgi-bin/index.pl?KataBowling © OPITZ CONSULTING 2017 UnitTests? Ja, aber richtig! 31 / 32
  32. 32. überraschend mehr Möglichkeiten! © OPITZ CONSULTING 2017 Vielen Dank für die Aufmerksamkeit. Thomas Papendieck Senior–Consultant Norsk–Data–Straße 4 61348 Bad Homburg thomas.papendieck@opitz-consulting.com +49 6172 66260 1523 © OPITZ CONSULTING 2017 UnitTests? Ja, aber richtig! 32 / 32

×