My Laws of Test Driven Development (2023)
Download as PPTX, PDF0 likes151 views
The document outlines 25 laws and guidelines for effective Test Driven Development (TDD) by Dennis Doomen, emphasizing design for testability and organizing code for clarity. It covers essential practices such as writing tests that drive design, appropriate use of mocking, and maintaining test scope alignment with boundaries. The author stresses the importance of tests serving as documentation and being designed clearly and effectively.
My Laws of Test Driven Development (2023)
- 1. Guidelines and heuristics that will help you reach the Plateau of Productivity My 25-ish “laws” of Test Driven Development Dennis Doomen @ddoomen | Principal Consultant | The Continuous Improver | Aviva Solutions
- 2. About Me Hands-on architect in the .NET space with 26 years of experience on an everlasting quest for knowledge to build the right software the right way at the right time @ddoomen | Principal Consultant | The Continuous Improver | Aviva Solutions
- 4. The Adoption Cycle for Test Driven Development @ddoomen | Principal Consultant | The Continuous Improver | Aviva Solutions
- 5. Design for Testability @ddoomen | Principal Consultant | The Continuous Improver | Aviva Solutions
- 6. Design class responsibilities Write first test Generate stubs Fail for the right reason Implement real deal Ensure test succeeds Identify alternative scenarios Repeat twice Refactor Start designing responsibilities before you write your first test
- 7. Then use the tests to drive the design further @ddoomen | Principal Consultant | The Continuous Improver | Aviva Solutions
- 8. Organize code by functionalities / capabilities
- 9. Use the Dependency Inversion Principle to decouple boundaries Order Processing IStoreOrders<T> + Query<T>(); + Add<T>(); + Delete<T>(); NHibernate Repository Order Processing IStoreOrders + GetIncompleteOrders(minValue); + StoreOrder(); + CompleteOrder(); OrderRepository VS @ddoomen | Principal Consultant | The Continuous Improver | Aviva Solutions
- 10. Apply DRY within those boundaries Duplicated Service 1 Duplicated Service 1 Duplicated Service 2 Duplicated Service 2 Duplicated Service 1 Centralized Service 3 Extension Methods Extension Methods Extension Methods Extension Methods Helpers Helpers Helpers Helpers
- 11. Use the right scope Dennis Doomen | @ddoomen | The Continuous Improver
- 12. Service Service Service Service Service Centralized Service Align your test scope with those “boundaries”
- 13. But sometimes, testing smaller is fine too Application Functional Slice Service Critical Internal Component Internal Component
- 14. Test things designed to reusable separately…
- 15. …but test implementation details as part of a bigger scope
- 16. Treat adjacent folders as separate boundaries
- 17. Test the real surface area
- 18. It’s fine to include the database
- 19. Clarify the arrange, act and assert
- 20. But use a different style if that helps
- 21. Don’t bother defining what “unit” vs “integration” is
- 22. Test guidelines Dennis Doomen | @ddoomen | The Continuous Improver
- 23. Write your tests like you write your production code
- 24. Allow your tests to be used as documentation
- 25. It’s fine to inject concrete classes inside boundaries @ddoomen | Principal Consultant | The Continuous Improver | Aviva Solutions
- 26. Use mocking between boundaries but avoid using them internally Service Service Service Service Service Centralized Service Can use mocking Can use mocking Can use mocking Can use mocking Avoid mocking Avoid mocking Avoid mocking @ddoomen | Principal Consultant | The Continuous Improver | Aviva Solutions
- 27. Don’t return mocks from mocks @ddoomen | Principal Consultant | The Continuous Improver | Aviva Solutions
- 28. Hide things that are not important for that specific test
- 29. Ensure it fails or succeeds for the right reason
- 30. Prefer inline literal strings and numbers over constants @ddoomen | Principal Consultant | The Continuous Improver | Aviva Solutions
- 31. Don’t use production code in assertions @ddoomen | Principal Consultant | The Continuous Improver | Aviva Solutions
- 32. Only assert what’s relevant for that specific test case @ddoomen | Principal Consultant | The Continuous Improver | Aviva Solutions
- 33. Keep out of the debugger hell
- 35. Postfix with Specs to emphasize tests are specifications
- 36. Group test by API or purpose using nested classes
- 37. Use short fact-based names.
- 38. Q&A (and win a 1-year license for the JetBrains Suite) …ping me at @ddoomen …email me at dennis.doomen@avivasolutions.nl