The document discusses problems with using mock objects in unit tests, such as brittle tests, and proposes alternatives like using stubs instead of mocks when possible. It also recommends refactoring code to separate concerns and make collaborators as simple as possible in order to reduce the need for mocks and stubs in tests. The overall message is that when tests require extensive mocking, it may be a sign the code could be redesigned for better testability.

1. © Zühlke 2014
Rick Janda, Immo Hüneke
Less mocking, less brittle tests – BCS SPA 2014
Stop Mocking and Get Real
1. July 2014
Slide 1 of 41

2. © Zühlke 2014
Kai Zen
Stop Mocking and Get Real | Rick Janda, Immo Hüneke 1. July 2014 Slide 2 of 41

6. © Zühlke 2014
Stop Mocking and Get Real
Rick Janda, Immo Hüneke
What could be the problem
with Mock Objects?
1. July 2014
Slide 6 of 41

7. © Zühlke 2014
• …test the "How" and not the "What"
– Lead to fragile tests, thanks to multiple dependencies
• …mirror the code of the Unit under Test
– Violate the D.R.Y. principle
• …test based on unvalidated assumptions
– Foster a false sense of security
• … have complicated syntax to setup
– Make tests hard to read
Mock Objects…
Stop Mocking and Get Real | Rick Janda, Immo Hüneke 1. July 2014 Slide 7 of 41

8. © Zühlke 2014
Tell, don't ask
• Some commentators recommend the "tell, don't ask"
style of coding interactions to reduce the amount of
distributed state
• Where a number of collaborators are needed to
complete an interaction, each one typically returns
some value that is used as input to the next
• This leads to a proliferation of mock objects
Stop Mocking and Get Real | Rick Janda, Immo Hüneke 1. July 2014 Slide 8 of 41

9. © Zühlke 2014
• Pain Killers – alleviate the symptoms
• Treatments – address the real causes of pain
Escape from Mocking Hell
Stop Mocking and Get Real | Rick Janda, Immo Hüneke 1. July 2014 Slide 9 of 41

10. © Zühlke 2014
Stop Mocking and Get Real
Rick Janda, Immo Hüneke
- 3 Pain Killers -
1. July 2014
Slide 10 of 41

11. © Zühlke 2014
Pain Killer I: Use Stubs instead of Mocks
Stop Mocking and Get Real | Rick Janda, Immo Hüneke 1. July 2014 Slide 11 of 41

12. © Zühlke 2014
What does the test need to assert?
1. July 2014Stop Mocking and Get Real | Rick Janda, Immo Hüneke Slide 12 of 41

13. © Zühlke 2014
Use mocks only where needed (e.g. to test
collaboration or to inject return values)
1. July 2014Stop Mocking and Get Real | Rick Janda, Immo Hüneke Slide 13 of 41

14. © Zühlke 2014
Pain Killer II:
Give Unit Tests a single responsibility.
Stop Mocking and Get Real | Rick Janda, Immo Hüneke 1. July 2014 Slide 14 of 41

15. © Zühlke 2014
What can a unit test assert?
• Return value
• State of the UUT (Unit Under Test)
• State of a collaborator
• Behaviour of the UUT against a collaborator
Choose which of these your test is designed to prove.
Stop Mocking and Get Real | Rick Janda, Immo Hüneke 1. July 2014 Slide 15 of 41

16. © Zühlke 2014
Pain Killer III: Hand-code test doubles or
use library classes where possible
Stop Mocking and Get Real | Rick Janda, Immo Hüneke 1. July 2014 Slide 16 of 41

17. © Zühlke 2014
• ByteArrayInputStream and ByteArrayOutputStream for Streams
– Make assertions about the toString() result
– Allow changes in the how.
• CharArrayReader and CharArrayWriter for Reader/Writer
– Very similar
• MockHttpSession, MockHttpServletRequest and MockHttpServletResponse
for Servlet API interfaces
– part of Spring Testing
Examples
Stop Mocking and Get Real | Rick Janda, Immo Hüneke 1. July 2014 Slide 17 of 41

18. © Zühlke 2014
Stop Mocking and Get Real
Rick Janda, Immo Hüneke
Treatments that address
the causes of pain
Why do we use Mocks or Stubs in Unit Tests?
1. July 2014
Slide 18 of 41

19. © Zühlke 2014
Collaborators can be placed on an “awkwardness scale”
Test Doubles as Substitute Collaborators
1. July 2014Stop Mocking and Get Real | Rick Janda, Immo Hüneke Slide 19 of 41
|| | | | || | | | || | | | || | | | || | | | || | | | || | | | || | | | || | | | || | | | || | | | || | | | || | | | || | | | || | | | || | | | || | | | || | | | || | | | || | | | || | | | || | | | || | | | || | | | |
Simple and straightforward Hard AwkwardSoft Awkward

20. © Zühlke 2014
• Slow
• Hard to create
• Hard to control
Typical of physical resources or runtime environment:
• I/O
• Network
• Timer
• Stochastic
• Container
• Process
Awkward Collaborators
1. July 2014 Slide 20 of 41

21. © Zühlke 2014
• Fast
• Easy to create
• Easy to setup
• Easy access to state
Typical of more intelligent data structures:
• Value Objects or Transfer Objects
• Entities
• Composite data structures (Mapped XML or JSON)
• also: Method objects
Simple Collaborators
1. July 2014Stop Mocking and Get Real | Rick Janda, Immo Hüneke Slide 21 of 41

22. © Zühlke 2014
Simple Rule
1. July 2014Stop Mocking and Get Real | Rick Janda, Immo Hüneke Slide 22 of 41

23. © Zühlke 2014
- Design Changes -
Reducing the need for mocks and stubs
1. July 2014Stop Mocking and Get Real | Rick Janda, Immo Hüneke Slide 23 of 41

24. © Zühlke 2014
Tackle the causes of awkwardness
1. July 2014Stop Mocking and Get Real | Rick Janda, Immo Hüneke Slide 24 of 41

25. © Zühlke 2014
Isolation combats infection
1. July 2014Stop Mocking and Get Real | Rick Janda, Immo Hüneke Slide 25 of 41

26. © Zühlke 2014
Separation of concerns – an analogy
1. July 2014Stop Mocking and Get Real | Rick Janda, Immo Hüneke Slide 26 of 41

27. © Zühlke 2014
Categorise objects by their role
… refactoring where necessary
1. July 2014Stop Mocking and Get Real | Rick Janda, Immo Hüneke Slide 27 of 41

28. © Zühlke 2014
Refactoring for testability:
Separate concerns by subdividing methods
1. July 2014Stop Mocking and Get Real | Rick Janda, Immo Hüneke Slide 28 of 41

29. © Zühlke 2014
Refactoring for testability:
Separate concerns by redistributing code
1. July 2014Stop Mocking and Get Real | Rick Janda, Immo Hüneke Slide 29 of 41

30. © Zühlke 2014
Primary Constructor
• Eliminate need to inject an awkward collaborator by providing an
alternative constructor just used in testing
Pull out query to awkward collaborator
• Make query result an argument to a simple testable method
Separate decision making from decision execution
• Create a testable decision making method that returns selector or
argument values
• Use the result to invoke collaboration with awkward collaborator
Function below – objects above
• Organise functions under objects – simplify function arguments
Refactoring for testability:
Move the logic to the leaves
1. July 2014Stop Mocking and Get Real | Rick Janda, Immo Hüneke Slide 30 of 41

31. © Zühlke 2014
Extract Awkwardness into Adapters
1. July 2014Stop Mocking and Get Real | Rick Janda, Immo Hüneke Slide 31 of 41

32. © Zühlke 2014
Build Rich Domain Objects
1. July 2014Stop Mocking and Get Real | Rick Janda, Immo Hüneke Slide 32 of 41

33. © Zühlke 2014
After Separation into Awkward / Simple
1. July 2014Stop Mocking and Get Real | Rick Janda, Immo Hüneke Slide 33 of 41

34. © Zühlke 2014
Architecture for Testability:
Simple Core – Awkward Shell
1. July 2014Stop Mocking and Get Real | Rick Janda, Immo Hüneke Slide 34 of 41

35. © Zühlke 2014
Simple Core – Awkward Shell example
1. July 2014Stop Mocking and Get Real | Rick Janda, Immo Hüneke Slide 35 of 41

36. © Zühlke 2014
Architecture for Testability:
Simple Boundary
1. July 2014Stop Mocking and Get Real | Rick Janda, Immo Hüneke Slide 36 of 41

37. © Zühlke 2014
Simple Boundary Example:
Segregate the Awkward
1. July 2014Stop Mocking and Get Real | Rick Janda, Immo Hüneke Slide 37 of 41

38. © Zühlke 2014
Putting it All Together: Simple Core –
Awkward Shell & Simple Boundary
1. July 2014Stop Mocking and Get Real | Rick Janda, Immo Hüneke Slide 38 of 41

39. © Zühlke 2014
Your Tests Require Lots of Stubbing
and Mocking?
Change Your
Design
Towards
Better Testability!
Stop Mocking and Get Real | Rick Janda, Immo Hüneke 1. July 2014 Slide 39 of 41

40. © Zühlke 2014
Change Your Design for Better Testability
1. July 2014Stop Mocking and Get Real | Rick Janda, Immo Hüneke Slide 40 of 41

41. © Zühlke 2014
Remember…
1. July 2014Stop Mocking and Get Real | Rick Janda, Immo Hüneke Slide 41 of 41