Test Driven Development on Android (Kotlin Kenya)
Download as PPTX, PDF1 like540 views
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 (on Android) Kotlin Kenya Danny Preussler @PreusslerBerlin
- 4. about:me • Finished university in 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 2007 in 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.
- 7. TDD Brotherhood We swear that: We will not write a single line of code before writing a test
- 8. TDD Brotherhood ● Extreme Programming, Kent Beck 1999 ● TDD by Example, Kent Becks, 2003
- 9. TDD Brotherhood ● Just a 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 tests is bad code.” (Michael C. Feathers)
- 12. “any code without test is a legacy code.” (Michael C. Feathers)
- 13. “how do you know something works when you don’t have test for it?” (Robert ‘Uncle Bob’ Martin)
- 14. “Refactoring without good test coverage is changing shit” (Martin Fowler)
- 15. TDD is not about testing
- 16. The 3 rules of 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 rules of 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 rules of 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 rules of 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 rules of 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 •Make it fail •Make it work •Make it right micro-cycle (minutes)
- 22. Be precise: •You must not 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 must not 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 must not 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. WTF
- 26. Baby steps Based: our limited 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 •You need red: • as no one tests the tests
- 28. Red Green Refactor •In green: • 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. Let’s code
- 33. Start somewhere
- 35. Write the tests that forces you to write the code you want to write
- 45. Write the tests that forces you to write the code you want to write Tip: Create a list of tests on paper
- 47. Tests tell a story
- 48. Tests tell a story • Test your behaviour • Think about your domain
- 49. What to mock?
- 52. • Tests are meant for refactoring • Mocks often break on refactoring What about mocking
- 53. interface TrackRepository { suspend fun 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 •TDD changes the way what you test: Test1 Class1 Class2 Class3
- 56. What about mocking •TDD changes the way what you test: Test1 Class1
- 57. What about mocking •TDD changes the way what you test: Test1 Class1 Class2 Class3
- 58. What about mocking •Tests will become more solid Test1 ViewModel Repository API
- 59. What about mocking •Tests will become more solid Test1 ViewModel Repository API Store Reducer SideEffects
- 60. What about mocking •Tests will become more solid Test1 ViewModel Repository API Store Reducer SideEffects
- 61. What about mocking •Mock your outside dependency (modules) Test1 ViewModel Repository API Store Reducer SideEffects
- 62. That’s not a unit test!
- 63. That’s not a unit test!
- 64. TDD and tests •Kent Beck 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 •Kent Beck 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 •Kent Beck 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 •Kent Beck 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. TDD on Android
- 70. Android SDK under test • This used to do the trick: android { … testOptions { unitTests.returnDefaultValues = true }
- 71. java.lang.NullPointerException at android.support.v17.leanback.app.PlaybackSupportFragment.setupChild FragmentLayout(PlaybackSupportFragment.java:730) at android.support.v17.leanback.app.PlaybackSupportFragment.onStart(Pl aybackSupportFragment.java:899) Try to stay away from Activities/Fragments
- 72. Android SDK under test •Wrap things class BundleBuilder @Inject constructor() { operator fun invoke() = Bundle() }
- 73. Android SDK under test •Wrap things class BundleBuilder @Inject constructor() { operator fun invoke() = Bundle() operator fun invoke(vararg pairs: Pair<String, Any?>) = bundleOf(*pairs) }
- 74. Android SDK under test •Wrap things (keep it simple) @VisibleForTesting var bundleBuilder: () -> Bundle = { Bundle() }
- 75. ViewModels encapsualate view state testable
- 76. DATA BINDING!
- 80. Robolectric 4 •Android builds are 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, not dogmatic @RobolectricNeededAsOf(Uri::class) @RunWith(RobolectricTestRunner::class) class UploadStarterTest {
- 82. What’s left?
- 83. Whats left? • UI: Jetpack Compose!
- 84. What’s left? •Activities needs to be declared in manifest •Permissions for older devices
- 85. What’s left?
- 86. What’s left? • Manifest via lint lintOptions { check 'Registered' warningsAsErrors true }
- 87. What’s left? • Zero tolerance policy very valuable
- 88. What’s left? • Get access to merged manifest and resources: testOptions { unitTests.includeAndroidResources = true } com/android/tools/ test_config.properties
- 89. Code coverage?
- 90. What about code coverage In TDD 100% coverage is a side effect not a goal!
- 91. Is’nt that slow?
- 92. Isn’t it slow? Writing tests is slower than not writing tests. You’ll write at least as much test code as production code
- 93. Isn’t it slow? Writing tests is slower than not writing tests. You’ll write at least as much test code as production code
- 94. Isn’t it slow? Research shows that TDD: adds 10%—30% on initial costs = longer to complete their projects
- 95. Isn’t it slow? Research shows that TDD: •Reduces defect density by 60-90 % •Reduces production bug density by 40–80%
- 96. Without TDD, you spend a 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 spend a 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. Benefits of TDD
- 104. Benefits •YAGNI and KISS out of the box •No more over-engineering •Test all business needs •Minimize debugging •Minimize use of Android devices
- 105. Benefits •YAGNI and KISS out of the box •No more over-engineering •Test all business needs •Minimize debugging •Minimize use of Android devices
- 106. Benefits •YAGNI and KISS out of the box •No more over-engineering •Test all business needs •Minimize debugging •Minimize use of Android devices
- 107. Benefits •YAGNI and KISS out of the box •No more over-engineering •Test all business needs •Minimize debugging •Minimize use of Android devices
- 108. Benefits •YAGNI and KISS out 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 any time •Go home any time •No need for “flow”
- 113. “Never ask permission to 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
- 115. Grace Hopper "It's easier to ask forgiveness than it is to get permission."
- 116. "Test only if you would want it to work.” Kent Beck
- 117. If it's worth building, it's worth testing If it's not worth testing, why are you wasting your time working on it?
- 118. If it's worth building, 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. More resources
- 121. More resources • TDD what 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 Danny Preussler @PreusslerBerlin