Write Antifragile & Domain-Driven tests with ”Outside-in diamond” ◆ TDD
•
1 like•131 views
TDD is a game changer. It changed my dev life for good, no doubt. Having made almost all possible errors while practicing it over the years (more than 15 years of TDD practice), I have now ended up since many years with a style that provides me and my teams lots of efficiency and happiness. A style that Bruno Boucard and myself have called the “outside-in diamond” TDD. Something that help us to easily write both domain-driven, but also "Antifragile" tests. A session made at DDD Africa
More Related Content
Similar to Write Antifragile & Domain-Driven tests with ”Outside-in diamond” ◆ TDD
Similar to Write Antifragile & Domain-Driven tests with ”Outside-in diamond” ◆ TDD (20)
More from Thomas Pierrain
More from Thomas Pierrain (20)
Recently uploaded
Recently uploaded (20)
Write Antifragile & Domain-Driven tests with ”Outside-in diamond” ◆ TDD
- 1. Write Antifragile & Domain-Driven Tests with • THOMAS PIERRAIN (@TPIERRAIN) ACCEPTANCE TESTS (COARSE-GRAINED “UNIT” TESTS) UNIT TESTS (FINE-GRAINED) CONTRACT TESTS INTEGRATION TESTS QA SMOKE TESTS EXPLORATORY TESTS END-TO-END TESTS OUTSIDE-IN DIAMOND TDD
- 2. Disclaimers There is no silver bullet Your testing strategy & techniques must always be chosen accordingly to your context (both human & technical) As long as you understand your trade-offs there is no reason not to explore new paths… Thanks to Kent Beck, Martin Fowler, Michael Feathers, Nat Pryce & Steve Freeman for their great source of inspiration over the years #shouldersOfGiants
- 3. Preamble
- 4. BFF API Booking API E-commerce CRS API Central Reservation U d PSP API Payment U d • THOMAS PIERRAIN (@TPIERRAIN) Metasearch API Distribution U d Resorts Referential CMS API Property Management System (PMS) Stay U d U d Rates & Cancellation rules API Revenue Mgmt U d U d Hospitality U d Accounts API Loyalty API Marketing DDD LOVES… (Contextualized) Services
- 5. E-commerce Central Reservation U d Payment U d • THOMAS PIERRAIN (@TPIERRAIN) Distribution U d Resorts Referential Stay U d U d Revenue Mgmt U d U d U d Marketing Accounts API Loyalty API DDD LOVES… (Contextualized) Services BFF API Booking API CMS API PSP API CRS API Rates & Cancellation rules API Metasearch API Property Management System (PMS) Hospitality
- 6. • THOMAS PIERRAIN (@TPIERRAIN) DDD (& TDD) ALSO LOVES… DOMAIN HTTP HTTP API INFRASTRUCTURE OUR WEB API Ports & Adapters
- 7. • THOMAS PIERRAIN (@TPIERRAIN) DDD (& TDD) ALSO LOVE… DOMAIN HTTP INFRASTRUCTURE OUR WEB API Ports & Adapters Easy to test Protect Domain code from Infra fads Quick feedback (carpaccio-style slicing) Allow late architectural decisions Composable: modular-monolith ready HTTP API
- 8. • THOMAS PIERRAIN (@TPIERRAIN) DDD (& TDD) ALSO LOVE… DOMAIN INFRASTRUCTURE Ports & Adapters
- 9. • THOMAS PIERRAIN (@TPIERRAIN) DDD (& TDD) ALSO LOVE… DOMAIN HTTP INFRASTRUCTURE OUR WEB API Ports & Adapters HTTP API
- 10. Let’s talk about tests!
- 11. • THOMAS PIERRAIN (@TPIERRAIN) Different Types A WORLD OF TESTS ET Exploratory Tests (E2E) IT Integration Tests (Contract) AT (coarse-grained unit) Acceptance Tests UT (fine-grained) Unit Tests
- 12. Why do I do TDD?
- 13. Made me… • THOMAS PIERRAIN (@TPIERRAIN) TEST DRIVEN DEVELOP MENT More relaxed More efficient More relevant
- 14. TDD Workflows
- 21. Outside-in • THOMAS PIERRAIN (@TPIERRAIN) TEST DRIVEN DEVELOP MENT AT AT AT AT AT
- 22. Outside-in • THOMAS PIERRAIN (@TPIERRAIN) TEST DRIVEN DEVELOP MENT AT AT AT AT AT AT
- 33. Inside-out • THOMAS PIERRAIN (@TPIERRAIN) TEST DRIVEN DEVELOP MENT API UT UT UT UT UT UT UT AT AT
- 34. Workflows • THOMAS PIERRAIN (@TPIERRAIN) TEST DRIVEN DEVELOP MENT Outside-in Inside-out A P I … … A P I
- 35. Common pitfalls & mitigations
- 36. • THOMAS PIERRAIN (@TPIERRAIN) Beware of… TEST DRIVEN DEVELOP MENT 1. Fragile tests 2. Blind spots 3. Complex setups
- 38. • THOMAS PIERRAIN (@TPIERRAIN) TEST DRIVEN DEVELOP MENT AT UT UT UT UT UT UT AT uses API 1. Beware of… Fragile tests
- 39. • THOMAS PIERRAIN (@TPIERRAIN) TEST DRIVEN DEVELOP MENT UT UT AT UT UT UT UT AT uses API Now we want to change our implementation here 1. Beware of… Fragile tests
- 40. • THOMAS PIERRAIN (@TPIERRAIN) TEST DRIVEN DEVELOP MENT UT UT AT UT UT UT UT AT uses API 1. Beware of… Fragile tests
- 41. • THOMAS PIERRAIN (@TPIERRAIN) TEST DRIVEN DEVELOP MENT UT UT AT UT UT UT UT AT 😕 😕 😕 😕 😕 uses API 1. Beware of… Fragile tests 😕
- 42. • THOMAS PIERRAIN (@TPIERRAIN) TEST DRIVEN DEVELOP MENT UT UT AT UT UT UT UT AT 😕 😕 😕 😕 😕 uses API Fragile tests ➔ Less refactoring 😕
- 43. • THOMAS PIERRAIN (@TPIERRAIN) UT UT AT UT UT UT UT AT 😕 😕 😕 😕 😕 uses API TEST DRIVEN DEVELOP MENT Fragile tests MITIGATIONS • Do not test “implementations” • Focus on external behaviours instead (with Outside-in TDD) • Favor (coarse-grained unit) Acceptance tests over fine- grained unit tests A P … …
- 44. • THOMAS PIERRAIN (@TPIERRAIN) TEST DRIVEN DEVELOP MENT Disclaimer Test Coverage will be a visual help to identify blind spots in our code here It doesn’t mean that test coverage is a must 2. Beware of… Blind Spots
- 45. • THOMAS PIERRAIN (@TPIERRAIN) TEST DRIVEN DEVELOP MENT DOMAIN HTTP HTTP API INFRASTRUCTURE OUR WEB API 2. Beware of… Blind Spots
- 46. • THOMAS PIERRAIN (@TPIERRAIN) TEST DRIVEN DEVELOP MENT DOMAIN Test the domain code with { acceptance | unit tests } 2. Beware of… Blind Spots
- 47. • THOMAS PIERRAIN (@TPIERRAIN) TEST DRIVEN DEVELOP MENT DOMAIN HTTP API Test the domain code with { acceptance | unit tests } Test the infra code (i.e. Adapters) with contract (integration) tests 2. Beware of… Blind Spots
- 48. • THOMAS PIERRAIN (@TPIERRAIN) TEST DRIVEN DEVELOP MENT 2. Beware of… Blind Spots IT IT IT IT HTTP API CONTRACT TESTS DOMAIN AT AT AT AT AT AT AT AT AT AT AT AT AT AT AT 100% covered by Acceptance Tests
- 49. • THOMAS PIERRAIN (@TPIERRAIN) TEST DRIVEN DEVELOP MENT 2. Beware of… Blind Spots IT IT IT IT HTTP API CONTRACT TESTS DOMAIN AT AT AT AT AT AT AT AT AT AT AT AT AT AT AT 100% covered by Acceptance Tests As DEV we to write Domain- Driven tests
- 50. • THOMAS PIERRAIN (@TPIERRAIN) TEST DRIVEN DEVELOP MENT 2. Beware of… Blind Spots IT IT IT IT HTTP API CONTRACT TESTS DOMAIN AT AT AT AT AT AT AT AT AT AT AT AT AT AT AT 100% covered by Acceptance Tests As DEV we to write Domain- Driven tests
- 51. • THOMAS PIERRAIN (@TPIERRAIN) TEST DRIVEN DEVELOP MENT 2. Beware of… Blind Spots As DEV we don’t write enough integration tests Because they are slow to run & boring ➔ BUGS IT IT IT IT HTTP API CONTRACT TESTS DOMAIN AT AT AT AT AT AT AT AT AT AT AT AT AT AT AT 100% covered by Acceptance Tests As DEV we to write Domain- Driven tests
- 52. As DEV we don’t write enough integration tests Because they are slow to run & boring ➔ BUGS IT IT IT IT HTTP API CONTRACT TESTS DOMAIN AT AT AT AT AT AT AT AT AT AT AT AT AT AT AT 100% covered by Acceptance Tests As DEV we to write Domain- Driven tests • THOMAS PIERRAIN (@TPIERRAIN) TEST DRIVEN DEVELOP MENT Blind Spots MITIGATIONS • Detect bugs in Adapters via our beloved Acceptance tests • Include the Adapters code and stub only the I/Os BUGS
- 53. • THOMAS PIERRAIN (@TPIERRAIN) TEST DRIVEN DEVELOP MENT 3. Beware of… Complex setups
- 54. • THOMAS PIERRAIN (@TPIERRAIN) Test Suite for Rooms Availability TEST DRIVEN DEVELOP MENT 3. Beware of… Complex setups 740 lines of Init()
- 55. • THOMAS PIERRAIN (@TPIERRAIN) Test Suite for Rooms Availability TEST DRIVEN DEVELOP MENT 3. Beware of… Complex setups 740 lines of Init()
- 56. • THOMAS PIERRAIN (@TPIERRAIN) Test Suite for Rooms Availability TEST DRIVEN DEVELOP MENT 3. Beware of… Complex setups 740 lines of Init()
- 57. • THOMAS PIERRAIN (@TPIERRAIN) Test Suite for Rooms Availability TEST DRIVEN DEVELOP MENT 3. Beware of… Complex setups Tests using initialized fields ➔ side effects nightmare
- 58. • THOMAS PIERRAIN (@TPIERRAIN) MITIGATIONS • Avoid cognitive overload as much as possible The power of sameness • Favor local variables over test suite members Everything should be created from the test • Use Domain-Driven Builders to shorten and explicit the Arrange section of your tests • Treat your test code as production code! ➔ merciless refactoring TEST DRIVEN DEVELOP MENT 3. Beware of… Complex setups
- 59. • THOMAS PIERRAIN (@TPIERRAIN) Beware of… TEST DRIVEN DEVELOP MENT 1. Fragile tests 2. Blind spots 3. Complex setups
- 60. • THOMAS PIERRAIN (@TPIERRAIN) 1. Fragile tests 2. Blind spots 3. Complex setups Mitigations TEST DRIVEN DEVELOP MENT
- 61. • THOMAS PIERRAIN (@TPIERRAIN) 1. Fragile tests 2. Blind spots 3. Complex setups Mitigations TEST DRIVEN DEVELOP MENT
- 62. • THOMAS PIERRAIN (@TPIERRAIN) 1. Fragile tests 2. Blind spots 3. Complex setups Mitigations TEST DRIVEN DEVELOP MENT
- 68. • THOMAS PIERRAIN (@TPIERRAIN) Outside-in but… TEST DRIVEN DEVELOP MENT Double loop One and a half loop ( )
- 71. OUTSIDE-IN DIAMOND Read it as a sentence divided into 2 parts +
- 72. OUTSIDE-IN DIAMOND Fuzzers help us - to randomly detect hard-coded values or unsupported cases
- 73. OUTSIDE-IN DIAMOND Fuzzers help us - to randomly detect hard-coded values or unsupported case - to shorten our test setup
- 74. OUTSIDE-IN DIAMOND Builders allow Behavioral & Domain-Driven intentions (no tech details here)
- 75. OUTSIDE-IN DIAMOND Builders allow Behavioral & Domain-Driven intentions (no tech details here)
- 76. OUTSIDE-IN DIAMOND Builders allow Behavioral & Domain-Driven intentions (no tech details here)
- 77. OUTSIDE-IN DIAMOND Builders allow Behavioral & Domain-Driven intentions (no tech details here)
- 78. OUTSIDE-IN DIAMOND Builders allow Behavioral & Domain-Driven intentions (no tech details here)
- 79. OUTSIDE-IN DIAMOND Builders allow Behavioral & Domain-Driven intentions (no tech details here) Very important!
- 80. OUTSIDE-IN DIAMOND We test from the left-side Adapter (here a web controller) Injecting the result of our builder
- 81. OUTSIDE-IN DIAMOND We define the end-user request No I/O here, but we test the whole { black-box / component / API }
- 82. OUTSIDE-IN DIAMOND Helper method to sum-up in “one line” our assert intention
- 83. OUTSIDE-IN DIAMOND “One line” to hide our technical assertions towards DTOs etc.
- 84. OUTSIDE-IN DIAMOND “One line” to hide our technical assertions towards DTOs etc. “One line” to reuse the same check intention, but with various adapters
- 91. OUTSIDE-IN DIAMOND ARRANGE ACT ASSERT Fuzzers to shorten & speed setup Builders to shorten and “domain-driven” our test setup
- 93. Live code
- 94. Wrap up
- 95. Outside-in Diamond TDD • Elaborated from & for the people • Write fast & Antifragile tests ( refactoring ) • DDD but covers more blind spots on the tech side
- 96. Outside-in Diamond TDD • Elaborated from & for the people • Write fast & Antifragile tests ( refactoring ) • DDD but covers more blind spots on the tech side
- 97. Any Questions?
- 98. BINARY IS FOR MACHINE CODE IS FOR PEOPLE WE CARE PEOPLE Special thanks to: Bruno BOUCARD, Cyrille DUPUYDAUBY & Rui CARVALHO for their kind reviews & feedbacks