Diese Präsentation wurde erfolgreich gemeldet.
Die SlideShare-Präsentation wird heruntergeladen. ×

Clean Unit Test Patterns

Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Wird geladen in …3
×

Hier ansehen

1 von 85 Anzeige
Anzeige

Weitere Verwandte Inhalte

Diashows für Sie (20)

Andere mochten auch (20)

Anzeige

Ähnlich wie Clean Unit Test Patterns (20)

Aktuellste (20)

Anzeige

Clean Unit Test Patterns

  1. 1. C l e a n U n i t T e s t P a t t e r n s F r a n k A p p e l Blog: www.codeaffine.com Email: fappel@codeaffine.com Twitter: @frank_appel
  2. 2. C l e a n U n i t T e s t P a t t e r n s Why bother? Structure Isolation Runners and Rules Assertions Q&A
  3. 3. Who I am.. Independent Software Developer Blogger (http://codeaffine.com/blog) Stalwart of agile methods and TDD in particular
  4. 4. C l e a n U n i t T e s t P a t t e r n s Why bother? Structure Isolation Runners and Rules Assertions Q&A
  5. 5. Why bother?
  6. 6. Why bother? Test of too many concepts
  7. 7. Why bother?
  8. 8. Why bother? Mix of integration and unit test
  9. 9. Why bother?
  10. 10. Why bother? Missing of clean and recognizable test structure
  11. 11. Why bother?
  12. 12. Why bother? Tight coupling of unit under test and dependencies
  13. 13. Why bother?
  14. 14. Why bother? Poor maintainability and progression
  15. 15. Why bother?
  16. 16. Why bother? Don't do it!
  17. 17. C l e a n U n i t T e s t P a t t e r n s Why bother? Structure Isolation Runners and Rules Assertions Q&A
  18. 18. Test Structure Four Phases Pattern
  19. 19. Test Structure Four Phases Pattern Setup (Fixture)
  20. 20. Test Structure Four Phases Pattern Setup (Fixture) Exercise
  21. 21. Test Structure Four Phases Pattern Setup (Fixture) Exercise Verify
  22. 22. Test Structure Four Phases Pattern Setup (Fixture) Exercise Verify Teardown: cleaning up the fixture in case it is persistent.
  23. 23. Test Structure Four Phases Pattern Setup (Fixture) Exercise Verify Teardown: cleaning up the fixture in case it is persistent.
  24. 24. Test Structure Setup Patterns
  25. 25. Test Structure Setup Patterns Inline Setup
  26. 26. Test Structure Setup Patterns
  27. 27. Test Structure Setup Patterns
  28. 28. Test Structure Setup Patterns Delegate Setup
  29. 29. Test Structure Setup Patterns
  30. 30. Test Structure Setup Patterns
  31. 31. Test Structure Setup Patterns Implicit Setup
  32. 32. Test Structure Reusable Setup Helper Object Mother Test Fixture Registry Implementation either as stateless test helper class or, in case the helper holds references to fixture or SUT objects, as stateful test helper object.
  33. 33. Test Structure Implicit Teardown Teardown is all about housekeeping and adds no information at all to a particular test
  34. 34. Test Structure Corner Case Tests: Expected Exceptions Traditional approach: ugly try-catch block, mix of phases
  35. 35. Test Structure Corner Case Tests: Expected Exceptions
  36. 36. Test Structure Corner Case Tests: Expected Exceptions Expected Annotation Method: might swallow setup problems, limited verification capabilities
  37. 37. Test Structure Corner Case Tests: Expected Exceptions
  38. 38. Test Structure Corner Case Tests: Expected Exceptions ExpectedException Rule: Verification definition before execution phase
  39. 39. Test Structure Corner Case Tests: Expected Exceptions
  40. 40. Test Structure Corner Case Tests: Expected Exceptions Usage of a little execution utility and Java 8 Lambda expressions
  41. 41. C l e a n U n i t T e s t P a t t e r n s Why bother? Structure Isolation Runners and Rules Assertions Q&A
  42. 42. Isolation Dependencies: SUT and DOC The tested Unit is usually referred to as system under test (SUT) Components the SUT depends on are denoted as depended-on component (DOC) Test related problems with DOCs DOCs we cannot control might impede decent test verification DOCs might also slow down test execution DOC’s behavior may change unexpectedly e.g. due to the usage of a newer version of a third party library
  43. 43. Isolation Isolation – A Unit Tester’s SEP Field Test concerns seperately and keep tests independent of each other! Indirect Inputs and Outputs
  44. 44. Isolation Test Double Patterns A unit should be designed in a way that each DOC can be replaced by a so called Test Double, which is a lightweight stand-in component for the DOC. A DOC is provided using dependency injection or a service locator. This ensures a loosely coupled micro-architecture that allows replacement of the DOC with the test double.
  45. 45. Isolation Controlling Indirect Inputs with Stubs
  46. 46. Isolation Controlling Indirect Inputs with Stubs
  47. 47. Isolation Controlling Indirect Inputs with Stubs
  48. 48. Isolation Controlling Indirect Inputs with Stubs
  49. 49. Isolation Controlling Indirect Inputs with Stubs
  50. 50. Isolation Indirect Output Verification with Spies The spy records the number value of the invocation in the test double’s number field. This allows to verify the indirect output as shown here: record verify
  51. 51. Isolation What About Mocks?
  52. 52. Isolation What About Mocks? Behavior Verifcation
  53. 53. Isolation What About Mocks? Behavior Verifcation Invocation Verification
  54. 54. Isolation What About Mocks?
  55. 55. Isolation What About Mocks?
  56. 56. Isolation Spy or Mock? Mocks break the usual test structure Behavior verification is somewhat hidden but Mocks provide a precise stacktrace to the failure cause
  57. 57. Isolation Test Double Frameworks JMock, EasyMock mock based Mockito spy based
  58. 58. Isolation Test Double Frameworks Only create test doubles for types you own (indication for integration tests and an abstracting adapter layer) A test double should not return another test double (potential violation of law of demeter)
  59. 59. C l e a n U n i t T e s t P a t t e r n s Why bother? Structure Isolation Runners and Rules Assertions Q&A
  60. 60. Runners Suite and Categories Use @RunWith to specify a particular test processor
  61. 61. Runners Suite and Categories
  62. 62. Runners Suite and Categories
  63. 63. Runners Parameterized Tests Parameterized tests allow to run the same test against multiple data records provided as instance field(s) of the test case fields
  64. 64. Runners Parameterized Tests
  65. 65. Runners Parameterized Tests Specification of the Parameterized test processor using @RunWith
  66. 66. Runners Parameterized Tests
  67. 67. Runners Parameterized Tests Field initialization takes place by constructor injection. Each data record is provided by a particular collector method annotated with @Parameters data records initializations
  68. 68. Runners JUnitParams
  69. 69. Rules What are JUnit Rules? Rules provide a possibility to intercept test method calls similar as an AOP framework would do. TemporaryFolder for example removes automatically all created files and directories after a test run. A list of JUnit built-in Rules can be found at: https://github.com/junit-team/junit/wiki/Rules
  70. 70. Rules How does it work? y
  71. 71. Rules How does it work?
  72. 72. Rules How does it work? Test execution produces: before during after
  73. 73. Rules How does it work?
  74. 74. Rules How does it work?
  75. 75. C l e a n U n i t T e s t P a t t e r n s Why bother? Structure Isolation Runners and Rules Assertions Q&A
  76. 76. Assertions JUnit Assert The built-in assertion mechanism of JUnit is provided by the class org.junit.Assert: It is quite verbose and somewhat limited with respect to the expressiveness of assertions that require more complex predicates
  77. 77. Assertions Hamcrest A third-party library that claims to provide an API for creating flexible expressions of intent is Hamcrest: MatcherAssert.assertThat(...) evaluates the execution result (actual) against a predicate (matcher-expression) MatcherAssert provides an overloaded assertThat method for failure message specification
  78. 78. Assertions Hamcrest
  79. 79. Assertions Hamcrest
  80. 80. Assertions AssertJ The library AssertJ strives to improves verification by providing fluent assertions API: Assertions.assertThat(...) verifies the execution result (actual) against fluently added conditions The Assert instance provides the method describeAs(String) to specify a particular failure message
  81. 81. Assertions AssertJ
  82. 82. Assertions AssertJ
  83. 83. Assertions Which one to use? JUnit Assert is surely somewhat dated and less object-oriented Hamcrest matchers provide a clean separation of assertion and predicate definition AssertJ assertions score with a compact and easy to use programming style Hamcrest and AssertJ support custom matchers/assertions for domain specific types So now you are spoilt for choice…
  84. 84. C l e a n U n i t T e s t P a t t e r n s Why bother? Structure Isolation Runners and Rules Assertions Q&A
  85. 85. C l e a n U n i t T e s t P a t t e r n s References xUnit Test Patterns, Gerard Meszaros, 2007 Clean Code, Chapter 9: Unit Tests, Robert C. Martin, 2009 Growing Object-Oriented Software, Guided by Tests, Chapter 8, Steve Freeman, Nat Pryce, 2010 Practical Unit Testing with JUnit and Mockito, Appendix C. Test Spy vs. Mock, Tomek Kaczanowski, 2013 JUnit in a Nutshell: Yet Another JUnit Tutorial, http://www.codeaffine.com/2014/09/24/junit-nutshell-junit-tutorial, Frank Appel 2014 Clean JUnit Throwable-Tests with Java 8 Lambdas, http://www.codeaffine.com/2014/07/28/clean-junit-throwable-tests-with-java-8-lambdas/, Frank Appel 2014 F r a n k A p p e l Blog: www.codeaffine.com Email: fappel@codeaffine.com Twitter: @frank_appel

×