Downloaded 16 times
Uploaded byDanny Preussler
Test Driven Development on Android (Kotlin Kenya)
This document discusses test-driven development (TDD) and its application to Android development. It begins with an introduction to TDD, outlining its core principles and benefits. It describes the "red, green, refactor" process and emphasizes writing tests before code. It addresses challenges with testing Android code, such as dependencies on framework classes, and recommends strategies like wrapping classes to isolate dependencies. Finally, it outlines the benefits of TDD such as reduced bugs, improved design, and increased productivity over the long run despite initial slower development.
Test Driven Development on Android (Kotlin Kenya)
- 1. Test Driven Development (onAndroid) Kotlin Kenya Danny Preussler @PreusslerBerlin
- 4. about:me • Finished universityin 2001 • Switched to Java in 2003 • Switched to Kotlin in 2016 • Worked for eBay, Groupon, Viacom • Android Engineer at SoundCloud • GDE since 2016
- 5. about:sc • Founded 2007in Berlin, Germany • World’s largest open audio platform • 200 million tracks, 25 million creators (2019) • Around 500 employees • Playstore: 100,000,000+ installs • Ratings: 4.7 (5,500,500) Our Mission is to lead what’s next in music. Our Purpose is to accelerate creators' careers.
- 6.
- 7. TDD Brotherhood We swearthat: We will not write a single line of code before writing a test
- 8. TDD Brotherhood ● ExtremeProgramming, Kent Beck 1999 ● TDD by Example, Kent Becks, 2003
- 9. TDD Brotherhood ● Justa rediscovery ● test first was normal in early days of programming
- 10. ● Software Crafters ●Pair / Mob programming ● Trunk based development ● TDD ● Practise their craft with Katas The real TDD Brotherhood
- 11. “Code without testsis bad code.” (Michael C. Feathers)
- 12. “any code withouttest is a legacy code.” (Michael C. Feathers)
- 13. “how do youknow something works when you don’t have test for it?” (Robert ‘Uncle Bob’ Martin)
- 14. “Refactoring without good testcoverage is changing shit” (Martin Fowler)
- 15. TDD is not abouttesting
- 16. The 3 rulesof TDD •Create a unit tests that fails •Write just enough production code to makes that test pass. •Clean up the mess you just made. micro-cycle (minutes)
- 17. The 3 rulesof TDD •Create a unit tests that fails •Write just enough production code to makes that test pass. •Clean up the mess you just made. micro-cycle (minutes)
- 18. The 3 rulesof TDD •Create a unit tests that fails •Write just enough production code to makes that test pass. •Clean up the mess you just made. micro-cycle (minutes)
- 19. The 3 rulesof TDD •Create a unit tests that fails •Write just enough production code to makes that test pass. •Clean up the mess you just made. micro-cycle (minutes)
- 20. The 3 rulesof TDD •Create a unit tests that fails •Write just enough production code to makes that test pass. •Clean up the mess you just made. •REPEAT micro-cycle (minutes)
- 21. Red Green Refactor •Makeit fail •Make it work •Make it right micro-cycle (minutes)
- 22. Be precise: •You mustnot write more of a test than is sufficient to fail •Not compiling is failing! •You must not write more production code than is sufficient to make the currently failing test pass micro-cycle (minutes)
- 23. Be precise: •You mustnot write more of a test than is sufficient to fail •Not compiling is failing! •You must not write more production code than is sufficient to make the currently failing test pass. micro-cycle (minutes)
- 24. Be precise: •You mustnot write more of a test than is sufficient to fail •Not compiling is failing! •You must not write more production code than is sufficient to make the currently failing test pass. micro-cycle (minutes)
- 25.
- 26. Baby steps Based: ourlimited minds are not capable of two simultaneous goals: 1. Correct behavior. 2. Correct structure. https://www.flickr.com/photos/21561428@N03/4616816371
- 27. Red Green Refactor •Youneed red: • as no one tests the tests
- 28. Red Green Refactor •Ingreen: • Speed trumps design! • Make it dirty!
- 29. Red Green Refactor •One step at a time = Don’t get distracted!
- 30. Red Green Refactor •One step at a time = Don’t get distracted! • Think of new test -> write it down
- 31. Red Green Refactor •One step at a time = Don’t get distracted! • It’s getting ugly? -> write it down
- 32.
- 33.
- 35. Write the teststhat forces you to write the code you want to write
- 45. Write the teststhat forces you to write the code you want to write Tip: Create a list of tests on paper
- 46.
- 47. Tests tell astory
- 48. Tests tell astory • Test your behaviour • Think about your domain
- 49.
- 51.
- 52. • Tests aremeant for refactoring • Mocks often break on refactoring What about mocking
- 53. interface TrackRepository { suspendfun track(track: Urn): Track suspend fun tracks(tracks: List<Urn>): List<Track> What about mocking ● Mocks hardode implementation details
- 54. What about mocking •TDD changes the way what you test: Test1 Test2 Class1 Class2 Class3 Test3
- 55. What about mocking •TDDchanges the way what you test: Test1 Class1 Class2 Class3
- 56. What about mocking •TDDchanges the way what you test: Test1 Class1
- 57. What about mocking •TDDchanges the way what you test: Test1 Class1 Class2 Class3
- 58. What about mocking •Testswill become more solid Test1 ViewModel Repository API
- 59. What about mocking •Testswill become more solid Test1 ViewModel Repository API Store Reducer SideEffects
- 60. What about mocking •Testswill become more solid Test1 ViewModel Repository API Store Reducer SideEffects
- 61. What about mocking •Mockyour outside dependency (modules) Test1 ViewModel Repository API Store Reducer SideEffects
- 62. That’s not a unittest!
- 63. That’s not a unittest!
- 64. TDD and tests •KentBeck spoke about behavior of the system in his TDD book •A “unit” does not mean every class/method! Unit came from Blackbox! •TDD tests behaviors not implementation details! •What your software does, is stable! How it does this, is unstable! TDD what went wrong: https://www.youtube.com/watch?v=EZ05e7EMOLM
- 65. TDD and tests •KentBeck spoke about behavior of the system in his TDD book •A “unit” does not mean every class/method! Unit came from Blackbox! •TDD tests behaviors not implementation details! •What your software does, is stable! How it does this, is unstable! TDD what went wrong: https://www.youtube.com/watch?v=EZ05e7EMOLM
- 66. TDD and tests •KentBeck spoke about behavior of the system in his TDD book •A “unit” does not mean every class/method! Unit came from Blackbox! •TDD tests behaviors not implementation details! •What your software does, is stable! How it does this, is unstable! TDD what went wrong: https://www.youtube.com/watch?v=EZ05e7EMOLM
- 67. TDD and tests •KentBeck spoke about behavior of the system in his TDD book •A “unit” does not mean every class/method! Unit came from Blackbox! •TDD tests behaviors not implementation details! •What your software does, is stable! How it does this, is unstable! TDD what went wrong: https://www.youtube.com/watch?v=EZ05e7EMOLM
- 68. TDD and tests •unit test must be fast! • no databases • no network calls • if -> integration test martinfowler.com
- 69.
- 70. Android SDK undertest • This used to do the trick: android { … testOptions { unitTests.returnDefaultValues = true }
- 71.
- 72. Android SDK undertest •Wrap things class BundleBuilder @Inject constructor() { operator fun invoke() = Bundle() }
- 73. Android SDK undertest •Wrap things class BundleBuilder @Inject constructor() { operator fun invoke() = Bundle() operator fun invoke(vararg pairs: Pair<String, Any?>) = bundleOf(*pairs) }
- 74. Android SDK undertest •Wrap things (keep it simple) @VisibleForTesting var bundleBuilder: () -> Bundle = { Bundle() }
- 75.
- 76.
- 77.
- 78.
- 79.
- 80. Robolectric 4 •Android buildsare already slow! •Robolectric is just another “android device” •Not compatible with Junit5 •Still slower than pure junit •It’s goal: replace Espresso not JVM Tests
- 81. be pragmatic, notdogmatic @RobolectricNeededAsOf(Uri::class) @RunWith(RobolectricTestRunner::class) class UploadStarterTest {
- 82.
- 83. Whats left? • UI:Jetpack Compose!
- 84. What’s left? •Activities needsto be declared in manifest •Permissions for older devices
- 85.
- 86. What’s left? • Manifestvia lint lintOptions { check 'Registered' warningsAsErrors true }
- 87. What’s left? • Zerotolerance policy very valuable
- 88. What’s left? • Getaccess to merged manifest and resources: testOptions { unitTests.includeAndroidResources = true } com/android/tools/ test_config.properties
- 89.
- 90. What about codecoverage In TDD 100% coverage is a side effect not a goal!
- 91.
- 92. Isn’t it slow? Writingtests is slower than not writing tests. You’ll write at least as much test code as production code
- 93. Isn’t it slow? Writingtests is slower than not writing tests. You’ll write at least as much test code as production code
- 94. Isn’t it slow? Researchshows that TDD: adds 10%—30% on initial costs = longer to complete their projects
- 95. Isn’t it slow? Researchshows that TDD: •Reduces defect density by 60-90 % •Reduces production bug density by 40–80%
- 96. Without TDD, you spenda few weeks writing code which mostly works and spend the next year(s) "testing" and fixing many (but not all) of the bugs
- 97. With TDD, you spenda year writing code which actually works.
- 98. Isn’t it slow? •Single+ Initial feature will take longer •Bugfixing phase is shorter •Debugging disappears •Ci finds bugs before QA does • Long term it’s much faster no more big rewrite
- 99. Isn’t it slow? •Single+ Initial feature will take longer •Bugfixing phase is shorter •Debugging disappears •Ci finds bugs before QA does • Long term it’s much faster no more big rewrite
- 100. Isn’t it slow? •Single+ Initial feature will take longer •Bugfixing phase is shorter •Debugging disappears •Ci finds bugs before QA does • Long term it’s much faster no more big rewrite
- 101. Isn’t it slow? •Single+ Initial feature will take longer •Bugfixing phase is shorter •Debugging disappears •Ci finds bugs before QA does • Long term it’s much faster no more big rewrite
- 102. Isn’t it slow? •Single+ Initial feature will take longer •Bugfixing phase is shorter •Debugging disappears •Ci finds bugs before QA does • Long term it’s much faster no more big rewrite
- 103.
- 104. Benefits •YAGNI and KISSout of the box •No more over-engineering •Test all business needs •Minimize debugging •Minimize use of Android devices
- 105. Benefits •YAGNI and KISSout of the box •No more over-engineering •Test all business needs •Minimize debugging •Minimize use of Android devices
- 106. Benefits •YAGNI and KISSout of the box •No more over-engineering •Test all business needs •Minimize debugging •Minimize use of Android devices
- 107. Benefits •YAGNI and KISSout of the box •No more over-engineering •Test all business needs •Minimize debugging •Minimize use of Android devices
- 108. Benefits •YAGNI and KISSout of the box •No more over-engineering •Test all business needs •Minimize debugging •Minimize use of Android devices
- 109. Benefits •It’s Gamification ->fun •Small Changes -> Small Pull requests •Always know what’s next
- 110. Benefits •It’s Gamification ->fun •Small Changes -> Small Pull requests •Always know what’s next
- 111. Benefits •It’s Gamification ->fun •Small Changes -> Small Pull requests •Always know what’s next
- 112. Benefits •Less stressful •Interrupt anytime •Go home any time •No need for “flow”
- 113. “Never ask permissionto refactor. Never ask permission to write tests. You do these things because you KNOW they are the best way to go fast.“ Robert C Martin
- 114.
- 115. Grace Hopper "It's easierto ask forgiveness than it is to get permission."
- 116. "Test only ifyou would want it to work.” Kent Beck
- 117. If it's worthbuilding, it's worth testing If it's not worth testing, why are you wasting your time working on it?
- 118. If it's worthbuilding, it's worth testing If it's not worth testing, why are you wasting your time working on it?
- 119. TDD on Android? •Its possible! • Might feel extreme • But it’s fun! https://www.flickr.com/photos/chefranden/14838138493
- 120.
- 121. More resources • TDDwhat went wrong: https://www.youtube.com/watch?v=EZ05e7EMOLM • The three laws of TDD by Uncle Bob https://www.youtube.com/watch?v=AoIfc5NwRks • TDD for those who don't need it https://www.youtube.com/watch?v=a6oP24CSdUg
- 122. More resources • https://online-training.jbrains.ca/p/wbitdd-01 •https://medium.com/androiddevelopers/write-once-run- everywhere-tests-on-android-88adb2ba20c5 • github.com/sporttotal-tv/android-tdd-workshop
- 123. Join the Brotherhood DannyPreussler @PreusslerBerlin