Test doubles explained in Kotlin

Test doubles, also known as “mocks”, managed to gain a reputation for causing unreadable and hard-to-maintain tests. Is the screwdriver to blame for the inability to hammer in the nail?

In this talk, Jakub will go back to the origins of test doubles to explain scenarios when they’re best used. We’ll discuss various types of test doubles based on examples and show how to make them trustworthy. Finally, we’ll explore the possibilities of replacing auto-mocking libraries with hand-crafted test doubles using features of a modern programming language like Kotlin.

Transcript

1. JAKUB ZALAS TEST DOUBLES EXPLAINED by in
2. Jakub Zalas @jakub_zalas @jakzal mastodon.social/@jakub_zalas a.k.a. Kuba
3. * Quick introduction * Behaviour & Veri fi cation * The chain premise * Collaboration tests * Contract tests PLAN
4. xUnit Test Patterns Refactoring Test Code Gerard Meszaros 2007
30. https://blog.thecodewhisperer.com/permalink/integrated-tests-are-a-scam Beware the Integrated Tests Scam J. B. Rainsberger / @jbrains
34. DATA CALCULATIONS ACTIONS Grokking Simplicity Eric Normand 2021
36. “TEST A CHAIN BY TESTING EACH LINK” MICHAEL "GEEPAW" HILL https://www.geepawhill.org/2018/01/16/underplayed-the-chain-premise-in-depth/
42. WE GET TO CHOOSE WHEN AND WHERE WE BREAK THE DEPENDENCY CHAIN FOR TESTING
43. COLLABORATION TESTS
44. xUnit Test Patterns Refactoring Test Code Gerard Meszaros 2007
45. INDIRECT INPUT
49. STUB
50. STUB
51. STUB
52. STUB A REAL OBJECT, BUT A DUMMY WOULD WORK AS WELL.
53. STUB A STUB
54. STUB
55. STUB
56. STUB
57. STUB HAND-CRAFTED WITH A MOCKING FRAMEWORK
58. STUB
59. STUB
60. STUB
61. INDIRECT OUTPUT
65. SPYHAND-CRAFTED
66. SPYHAND-CRAFTED
67. SPYHAND-CRAFTED
68. SPYHAND-CRAFTED
69. SPYWITH A MOCKING FRAMEWORK
70. MOCK OBJECTWITH A MOCKING FRAMEWORK
71. MOCK OBJECTHAND-CRAFTED
72. MOCK OBJECTHAND-CRAFTED
73. FAKE OBJECT
74. FAKE OBJECT
75. FAKE OBJECT
76. CONTRACT TESTS a.k.a. "Role tests"
83. UnusualSpendingSensorTest
84. UnusualSpendingSensorTest PaymentRepositoryContractTest PaymentRepositoryContractTest
90. SEALING THE CONTRACT
91. SEALING THE CONTRACT
92. SEALING THE CONTRACT
93. SEALING THE CONTRACT
97. COMMON PITFALLS * Value mocking * Getters mocking * Unnecessary mocking * Mock orchestration / mimicking the implementation * Mocking disproportionally more complex than the code * Adding expectations on numbers of calls * Mocking 3rd party code
98. THANK YOU Verify behaviour, not implementation Mock roles, not objects Listen to your tests, let them guide your design Keep your tests as tidy as the codebase Leverage test doubles as a TDD tool @jakub_zalas @jakub_zalas @jakzal