Clean Unit Test Patterns
15 likes6,029 views
The document discusses clean unit test patterns, emphasizing the importance of structure, isolation, and proper assertions in unit testing. It highlights the stages of a test structure, the role of test doubles, and the use of frameworks like JUnit and AssertJ for improved testing practices. The document also explores dependency isolation and the implementation of various test runners and rules to enhance test reliability and maintainability.
Clean Unit Test Patterns
- 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. 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. Who I am.. Independent Software Developer Blogger (http://codeaffine.com/blog) Stalwart of agile methods and TDD in particular
- 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. Why bother?
- 6. Why bother? Test of too many concepts
- 7. Why bother?
- 8. Why bother? Mix of integration and unit test
- 9. Why bother?
- 10. Why bother? Missing of clean and recognizable test structure
- 11. Why bother?
- 12. Why bother? Tight coupling of unit under test and dependencies
- 13. Why bother?
- 14. Why bother? Poor maintainability and progression
- 15. Why bother?
- 16. Why bother? Don't do it!
- 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. Test Structure Four Phases Pattern
- 19. Test Structure Four Phases Pattern Setup (Fixture)
- 20. Test Structure Four Phases Pattern Setup (Fixture) Exercise
- 21. Test Structure Four Phases Pattern Setup (Fixture) Exercise Verify
- 22. Test Structure Four Phases Pattern Setup (Fixture) Exercise Verify Teardown: cleaning up the fixture in case it is persistent.
- 23. Test Structure Four Phases Pattern Setup (Fixture) Exercise Verify Teardown: cleaning up the fixture in case it is persistent.
- 24. Test Structure Setup Patterns
- 25. Test Structure Setup Patterns Inline Setup
- 26. Test Structure Setup Patterns
- 27. Test Structure Setup Patterns
- 28. Test Structure Setup Patterns Delegate Setup
- 29. Test Structure Setup Patterns
- 30. Test Structure Setup Patterns
- 31. Test Structure Setup Patterns Implicit Setup
- 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. Test Structure Implicit Teardown Teardown is all about housekeeping and adds no information at all to a particular test
- 34. Test Structure Corner Case Tests: Expected Exceptions Traditional approach: ugly try-catch block, mix of phases
- 35. Test Structure Corner Case Tests: Expected Exceptions
- 36. Test Structure Corner Case Tests: Expected Exceptions Expected Annotation Method: might swallow setup problems, limited verification capabilities
- 37. Test Structure Corner Case Tests: Expected Exceptions
- 38. Test Structure Corner Case Tests: Expected Exceptions ExpectedException Rule: Verification definition before execution phase
- 39. Test Structure Corner Case Tests: Expected Exceptions
- 40. Test Structure Corner Case Tests: Expected Exceptions Usage of a little execution utility and Java 8 Lambda expressions
- 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. 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. Isolation Isolation – A Unit Tester’s SEP Field Test concerns seperately and keep tests independent of each other! Indirect Inputs and Outputs
- 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. Isolation Controlling Indirect Inputs with Stubs
- 46. Isolation Controlling Indirect Inputs with Stubs
- 47. Isolation Controlling Indirect Inputs with Stubs
- 48. Isolation Controlling Indirect Inputs with Stubs
- 49. Isolation Controlling Indirect Inputs with Stubs
- 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. Isolation What About Mocks?
- 52. Isolation What About Mocks? Behavior Verifcation
- 53. Isolation What About Mocks? Behavior Verifcation Invocation Verification
- 54. Isolation What About Mocks?
- 55. Isolation What About Mocks?
- 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. Isolation Test Double Frameworks JMock, EasyMock mock based Mockito spy based
- 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. 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. Runners Suite and Categories Use @RunWith to specify a particular test processor
- 61. Runners Suite and Categories
- 62. Runners Suite and Categories
- 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
- 65. Runners Parameterized Tests Specification of the Parameterized test processor using @RunWith
- 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
- 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. Rules How does it work? y
- 71. Rules How does it work?
- 72. Rules How does it work? Test execution produces: before during after
- 73. Rules How does it work?
- 74. Rules How does it work?
- 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. 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. 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
- 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
- 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. 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. 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