About 15 years ago, I got inspired by a series of posts on Test Driven Development written by the Jeremy D. Miller. Now, with many years of great and not-so-great experiences practicing Test Driven Development, I thought it is the time to capture my own “laws”. The term "law" is obviously an exaggeration and "principles or heuristics" cover my intend much better. Either way, I want to talk about the scope of testing, using the observable behavior, naming conventions, state-based vs interaction-based testing, the impact of DRY, patterns to build useful test objects and some of the libraries and tools I use. In short, everything I try to follow every day I write, review or maintain code.

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

34. Naming and organization
#avivasolutions

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