Droidcon NYC: Beyond the Mockery

In software development, mocking is a popular technique used to simulate dependencies and test behaviour without relying on external systems. However, as with any technique, there are pros and cons to using mocks.

In this talk, I'll discuss why using mocks may not be the best approach and why we should instead use fakes or in-memory implementations of well-defined interfaces. We will explore the drawbacks of mocks, including how they can lead to brittle tests, slow down development, and make it difficult to refactor code.

By contrast, we will see how using fakes or in-memory implementations can provide faster feedback, increase confidence in the code, and make it easier to maintain tests as the codebase evolves. We will look at some examples of how to implement these alternatives, and how to make them useful in different testing scenarios.

Transcript

1. Beyond the Mockery Ash Davies ashdavies.dev | ashdavies@androiddev.social
2. Legacy (adj.) Denoting or relating to so!ware or hardware that has been superseded but is di"cult to replace because of its wide use. ashdavies.dev | ashdavies@androiddev.social
3. Change ashdavies.dev | ashdavies@androiddev.social
4. Testing ashdavies.dev | ashdavies@androiddev.social
5. Testing: Awareness ashdavies.dev | ashdavies@androiddev.social
6. Testing: Architecture ashdavies.dev | ashdavies@androiddev.social
7. Testing: Con!dence ashdavies.dev | ashdavies@androiddev.social
8. Testing: Documentation ashdavies.dev | ashdavies@androiddev.social
9. Testing: Stability ashdavies.dev | ashdavies@androiddev.social
10. Testing ashdavies.dev | ashdavies@androiddev.social
11. Testing • Unit • Instrumentation • Integration • End-to-End • Monkey • Smoke ashdavies.dev | ashdavies@androiddev.social
12. ashdavies.dev | ashdavies@androiddev.social
13. Anti-Pa!erns and Code Smell ashdavies.dev | ashdavies@androiddev.social
14. Extreme Programming Test-Driven Development ashdavies.dev | ashdavies@androiddev.social
15. Debugging is like being the detective in a crime movie where you are also the murderer. — Filipe Fo!es ashdavies.dev | ashdavies@androiddev.social
16. Kotlin (noun) Awesome. ashdavies.dev | ashdavies@androiddev.social
17. Kotlin: Mutability Risks of Mutation ashdavies.dev | ashdavies@androiddev.social
18. Kotlin: Mutability Risks of Mutation fun sumAbsolute(list: MutableList<Int>): Int { for (i in list.indices) list[i] = abs(list[i]) return list.sum() } ashdavies.dev | ashdavies@androiddev.social
19. Kotlin: Mutability Risks of Mutation private val GROUNDHOG_DAY = TODO("java.util.Date()") fun startOfSpring(): java.util.Date = GROUNDHOG_DAY val partyDate = startOfSpring() partyDate.month = partyDate.month + 1 // Date is mutable ! ashdavies.dev | ashdavies@androiddev.social
20. Kotlin: Mutability Shared Mutable State ashdavies.dev | ashdavies@androiddev.social
21. Kotlin: Immutability Unidirectional Data Flow ashdavies.dev | ashdavies@androiddev.social
22. Kotlin: Immutability Collections fun List<T>.toMutableList(): MutableList<T> fun Map<K, V>.toMutableMap(): MutableMap<K, V> fun Set<T>.toMutableSet(): MutableSet<T> ashdavies.dev | ashdavies@androiddev.social
23. Kotlin: Immutability IntelliJ IDEA ashdavies.dev | ashdavies@androiddev.social
24. Kotlin: Immutability Final Concretions By default, Kotlin classes are !nal – they can't be inherited ashdavies.dev | ashdavies@androiddev.social
25. Kotlin: Immutability Final Concretions open class Base // Class is open for inheritance ashdavies.dev | ashdavies@androiddev.social
26. Kotlin: Immutability All-Open Compiler Plugin org.jetbrains.kotlin.plugin.allopen ashdavies.dev | ashdavies@androiddev.social
27. Anti-Pa!erns and Code Smell ashdavies.dev | ashdavies@androiddev.social
28. Refactoring: Dependencies ashdavies.dev | ashdavies@androiddev.social
29. Refactoring: Dependencies =================================================================== diff --git a/CoffeeMaker.kt b/CoffeeMaker.kt - internal class CoffeeMaker { - private val heater: Heater = ElectricHeater() - private val pump: Pump = Thermosiphon(heater) - } + internal class CoffeeMaker( + private val heater: Heater, + private val pump: Pump, + ) ashdavies.dev | ashdavies@androiddev.social
30. Refactoring: Dependencies =================================================================== diff --git a/CoffeeMaker.kt b/CoffeeMaker.kt + internal class CoffeeMaker( + private val heater: Heater, - private val thermosiphon: Thermosiphon, + private val pump: Pump, + ) + + internal interface Pump { + fun pump() + } + - internal class Thermosiphon { + internal class Thermosiphon : Pump { ashdavies.dev | ashdavies@androiddev.social
31. Testing: Dependencies Dependency Injection internal class CoffeeMaker( private val heater: Heater, private val pump: Pump, ) ashdavies.dev | ashdavies@androiddev.social
32. Testing: Dependencies Dependency Injection val heater = NuclearFusionHeater() // Expensive! val maker = CoffeeMaker( pump = Thermosiphon(heater), heater = heater, ) assertTrue(maker.brew()) ashdavies.dev | ashdavies@androiddev.social
33. Testing: Dependencies Dependency Injection val heater = DiskCachedHeater() // Stateful! val maker = CoffeeMaker( pump = Thermosiphon(heater), heater = heater, ) assertTrue(maker.brew()) ashdavies.dev | ashdavies@androiddev.social
34. Testing: Dependencies Dependency Injection val heater = UnbalancedHeater() // Error prone! val maker = CoffeeMaker( pump = Thermosiphon(heater), heater = heater, ) assertTrue(maker.brew()) ashdavies.dev | ashdavies@androiddev.social
35. Testing: Dependencies Test Doubles ashdavies.dev | ashdavies@androiddev.social
36. Testing: Dependencies Mocks ashdavies.dev | ashdavies@androiddev.social
37. Testing: Dependencies Mockito "Tasty mocking framework for unit tests in Java". ashdavies.dev | ashdavies@androiddev.social
38. Testing: Mocks val heater = mock<Heater>() val pump = mock<Pump>() val maker = CoffeeMaker( heater = heater, pump = pump, ) assertTrue(maker.brew()) ashdavies.dev | ashdavies@androiddev.social
39. Testing: Mocks val heater = mock<Heater>() val pump = mock<Pump>() val maker = CoffeeMaker( heater = heater, pump = pump, ) assertTrue(maker.brew()) // ⚠ Fails! ashdavies.dev | ashdavies@androiddev.social
40. Testing: Mocks val heater = mock<Heater> { on { isHeating } doAnswer { true } } val pump = mock<Pump> { on { pump() } doAnswer { true } } val maker = CoffeeMaker( heater = heater, pump = pump, ) assertTrue(maker.brew()) ashdavies.dev | ashdavies@androiddev.social
41. Testing: Mocks javadoc.io/doc/ org.mockito/mockito-core/latest/ org/mockito/Mockito.html ashdavies.dev | ashdavies@androiddev.social
42. Testing: Mocks Footguns ashdavies.dev | ashdavies@androiddev.social
43. Testing: Mocks Accidental Invocation val heater = mock<Heater> { on { isHeating } doAnswer { true } // Actual invocation! } ashdavies.dev | ashdavies@androiddev.social
44. Testing: Mocks Accidental Invocation spy(emptyList<String>()) { on { get(0) } doAnswer { "foo" } // throws IndexOutOfBoundsException } ashdavies.dev | ashdavies@androiddev.social
45. Testing: Mocks API Sensitivity internal interface Heater { val isHeating: Boolean } val heater = mock<Heater> { on { isHeating } doAnswer { true } } ashdavies.dev | ashdavies@androiddev.social
46. Testing: Mocks API Sensitivity internal interface Heater { + fun <T : Any> heat(body: () -> T): T val isHeating: Boolean } val heater = mock<Heater> { on { isHeating } doAnswer { true } } ashdavies.dev | ashdavies@androiddev.social
47. Testing: Mocks API Sensitivity internal interface CoffeeDistributor { fun announce(vararg name: String): Boolean } val mockDistributor = mock<CoffeeDistributor> { on { announce(any(), any()) } doReturn true } val announced = mockDistributor.announce( "Steve", "Roger", "Stan", ) assertTrue(announced) // False: We only stubbed two names! ashdavies.dev | ashdavies@androiddev.social
48. Testing: Mocks Default Answers val heater: Heater = mock() // No default answer val isHeating: Boolean = heater.isHeating // Null ashdavies.dev | ashdavies@androiddev.social
49. Testing: Mocks Default Answers val heater: Heater = mock(defaultAnswer = RETURNS_SMART_NULLS) val isHeating: Boolean = heater.isHeating // false ashdavies.dev | ashdavies@androiddev.social
50. Testing: Mocks Default Answers • CALLS_REAL_METHODS • RETURNS_DEEP_STUBS • RETURNS_DEFAULTS • RETURNS_MOCKS • RETURNS_SELF • RETURNS_SMART_NULLS ashdavies.dev | ashdavies@androiddev.social
51. Testing: Mocks Type Safety public interface OngoingStubbing<T> { OngoingStubbing<T> thenAnswer(Answer<?> answer); } ashdavies.dev | ashdavies@androiddev.social
52. Testing: Mocks Pe!ormance Expensive real implementations replaced by expensive mocks. • Runtime code generation • Bytecode manipulation • Re!ection ! ashdavies.dev | ashdavies@androiddev.social
53. Testing: Mocks Pe!ormance internal class CoffeeMakerTest { private lateinit var heater: Heater @Before fun setUp() { heater = mock { on { isHeating } doAnswer { true } } } } ashdavies.dev | ashdavies@androiddev.social
54. Testing: Mocks Dynamic Mutability internal class CoffeeMakerTest { private lateinit var heater: Heater @Before fun setUp() { heater = mock { on { isHeating } doAnswer { true } } } @Test fun `should brew coffee`() { // heater already has state! } } ashdavies.dev | ashdavies@androiddev.social
55. Testing: Mocks Dynamic Mutability Framework generated mocks introduce a shared, mutable, dynamic, runtime declaration. ashdavies.dev | ashdavies@androiddev.social
56. Unpredictability Costs ashdavies.dev | ashdavies@androiddev.social
57. Unpredictability: Costs Learning Curve ashdavies.dev | ashdavies@androiddev.social
58. Unpredictability: Costs Peer Review ashdavies.dev | ashdavies@androiddev.social
59. Unpredictability: Costs Risk of Bugs ashdavies.dev | ashdavies@androiddev.social
60. Unpredictability: Costs Slowed Feature Delivery ashdavies.dev | ashdavies@androiddev.social
61. Unpredictability Victims • Junior developers • New team members • Future you ashdavies.dev | ashdavies@androiddev.social
62. Testing: Mocks Don't Mock Classes You Don't Own testing.googleblog.com/2020/07/testing-on-toilet-dont-mock-types-you.html ashdavies.dev | ashdavies@androiddev.social
63. You Don't Own Your Code! Your code belongs to your team. Be considerate. ashdavies.dev | ashdavies@androiddev.social
64. Testing: Mocks Considerations ashdavies.dev | ashdavies@androiddev.social
65. Testing: Mocks Interaction Veri!cation ashdavies.dev | ashdavies@androiddev.social
66. Testing: Mocks What Now? ashdavies.dev | ashdavies@androiddev.social
67. Testing: Stubs ashdavies.dev | ashdavies@androiddev.social
68. Testing: Stubs Simple internal interface Pump { fun pump(): Boolean } internal object StubPump : Pump { override fun pump(): Boolean = true } ashdavies.dev | ashdavies@androiddev.social
69. Testing: Stubs Idiomatic internal fun interface Pump { fun pump(): Boolean } val stub = Pump { true } ashdavies.dev | ashdavies@androiddev.social
70. Testing: Stubs API Sensitive + private const val DEFAULT_AMOUNT = 250 // ml + - internal fun interface Pump { + internal interface Pump { - fun pump(): Boolean + fun pump(amount: Int = DEFAULT_AMOUNT): Boolean + } ashdavies.dev | ashdavies@androiddev.social
71. Testing: Stubs API Sensitive private const val DEFAULT_AMOUNT = 250 // ml internal interface Pump { fun pump(amount: Int = DEFAULT_AMOUNT): Boolean } val stub = Pump { true } // Compilation failure... ashdavies.dev | ashdavies@androiddev.social
72. Testing: Fakes ashdavies.dev | ashdavies@androiddev.social
73. Testing: Fakes public class FakePump(private val onPump: (Boolean) -> Boolean) : Pump { public val pumped = mutableListOf<Pair<Boolean, Boolean>>() override fun pump(full: Boolean): Boolean = onPump(full).also { pumped += full to it } } ashdavies.dev | ashdavies@androiddev.social
74. Testing: Fakes Additional Behaviour private class DelegatingHeater( private val delegate: Heater, ) : Heater by delegate { private val _drinks = mutableListOf<Any>() val drinks: List<Any> by ::_drinks override fun <T : Any> heat(body: () -> T): T { return delegate.heat(body).also { _drinks += it } } } ashdavies.dev | ashdavies@androiddev.social
75. Testing: Fakes Authoring ashdavies.dev | ashdavies@androiddev.social
76. Testing: Fakes Responsibility ashdavies.dev | ashdavies@androiddev.social
77. Testing: Fakes Quali!cations Those who wrote the code are the most uniquely quali!ed to write the tests. ashdavies.dev | ashdavies@androiddev.social
78. Testing: Libraries • androidx.compose.ui:ui-test-junit4 • com.slack.circuit:circuit-test • io.ktor:ktor-server-test-host • io.ktor:ktor-client-mock • kotlinx-coroutines-test ashdavies.dev | ashdavies@androiddev.social
79. Testing: In Memory internal fun interface CoffeeStore { fun has(type: CoffeeType): Boolean } internal enum class CoffeeType { CAPPUCCINO, ESPRESSO, LATTE, } ashdavies.dev | ashdavies@androiddev.social
80. Testing: In Memory internal class InMemoryCoffeeStore : CoffeeStore { private val _stock = mutableMapOf<CoffeeType, Int>() val stock: Map<CoffeeType, Int> by ::_stock override fun has(type: CoffeeType): Boolean { return (_stock[type] ?: 0) > 0 } fun add(type: CoffeeType, amount: Int = 1) { _stock[type] = (_stock[type] ?: 0) + amount } } ashdavies.dev | ashdavies@androiddev.social
81. Testing: In Memory Bonus! In-memory implementations for local or network overrides. ashdavies.dev | ashdavies@androiddev.social
82. Reality ashdavies.dev | ashdavies@androiddev.social
83. Inte!ace Segregation Principle No code should be forced to depend on methods it does not use. Image: dribbble.com/shots/3251806-Inte!ace-Segregation-Principle
84. Anti-Pa!erns and Code Smell Refactoring: Seams ashdavies.dev | ashdavies@androiddev.social
85. Refactoring: Seams Preprocessing • Kotlin Symbol Processing • Kotlin Compiler Plugins ashdavies.dev | ashdavies@androiddev.social
86. Refactoring: Seams Linking: Classpath import fit.Parser internal class FitFilter { private val parser: Parser = Parser.newInstance() } ashdavies.dev | ashdavies@androiddev.social
87. Refactoring: Seams Linking: Classpath buildscript { dependencies { val googleServicesVersion = libs.versions.google.services.get() classpath("com.google.gms:google-services:$googleServicesVersion") } } ashdavies.dev | ashdavies@androiddev.social
88. Refactoring: Seams Objects internal class FitFilter { private val parser: Parser = Parser.newInstance() } ashdavies.dev | ashdavies@androiddev.social
89. Refactoring: Seams ! Objects: Refactoring =================================================================== diff --git a/FitFilter.kt b/FitFilter.kt - internal class FitFilter { - private val parser: Parser = - Parser.newInstance() - } - + internal fun interface FitFilter { + fun filter(input: String): String + } + + internal fun FitFilter(parser: Parser) = FitFilter { input -> + parser.parse(input) + } ashdavies.dev | ashdavies@androiddev.social
90. Everything is an API ashdavies.dev/talks/everything-is-an-api-berlin-droidcon/ Build versatile and scalable applications with careful API decisions. ashdavies.dev | ashdavies@androiddev.social
91. Testing: Android Legacy Inheritance ashdavies.dev | ashdavies@androiddev.social
92. android.content.Co ntext ashdavies.dev | ashdavies@androiddev.social
93. God Objects ashdavies.dev | ashdavies@androiddev.social
94. Ravioli Code ashdavies.dev | ashdavies@androiddev.social
95. Conclusion • Don’t mock classes you don’t own. • Don’t mock classes you do own. • Don’t mock classes (except Context). ashdavies.dev | ashdavies@androiddev.social
96. Every existing thing is born without reason, prolongs itself out of weakness, and dies by chance. — Jean-Paul Sa!re ashdavies.dev | ashdavies@androiddev.social
97. Thanks! ashdavies.dev/talks/beyond-the-mockery-berlin/ ashdavies.dev | ashdavies@androiddev.social
98. Fu!her Reading • Ma!in Flower: Mocks Aren't Stubs ma!infowler.com/a!icles/mocksArentStubs.html • Ma!in Fowler: Practical Test Pyramid ma!infowler.com/a!icles/practical-test-pyramid.html • Images: Monkey User monkeyuser.com • Michael Feathers: Working E"ectively with Legacy Code ISBN: 978-0-13117-705-5 • Steve Freeman, Nat Pryce: Growing Object-Oriented So#ware, Guided by Tests ISBN: 978-0-32150-362-6 • Testing on the Toilet: Don't mock Types You Don't Own testing.googleblog.com/2020/07/testing-on-toilet-dont-mock-types-you.html • Testing on the Toilet: Know Your Test Doubles testing.googleblog.com/2013/07/testing-on-toilet-know-your-test-doubles.html ashdavies.dev | ashdavies@androiddev.social