Download to read offline
Uploaded byDanny Preussler
TDD on Android (Øredev 2018)
The document is a presentation by Danny Preussler discussing Test-Driven Development (TDD) on Android, emphasizing the importance of tests in ensuring code quality and confidence in functionality. It outlines the history and rules of TDD, explains its advantages such as improved code structure and reduced defects, and addresses common misconceptions regarding the time investment and challenges of implementing TDD in Android development. Additionally, it provides insights on how to effectively write and manage tests within the Android framework.
More Related Content
Similar to TDD on Android (Øredev 2018)
TDD on Android (Øredev 2018)
- 1. TDD on Android Danny Preussler,Øredev 2018
- 2. @PreusslerBerlin about:me • Switched toJava in 2003 • Talking about testing on mobile since 2008 • Worked for eBay, Groupon, Viacom
- 3.
- 4. @PreusslerBerlin “Code without testsis bad code.” “any code without test is a legacy code.” (Michael C. Feathers)
- 5. @PreusslerBerlin “Code without testsis bad code.” “any code without test is legacy code.” (Michael C. Feathers)
- 6. @PreusslerBerlin Tests give confidence “howdo you know something works when you don’t have test for it?” (Robert ‘Uncle Bob’ Martin)
- 7. @PreusslerBerlin Tests allow refactoring “Refactoringwithout good test coverage is changing shit” (Martin Fowler)
- 8.
- 9. @PreusslerBerlin History • Started withtest first from XP in 1999 by Kent Beck • Just a rediscovery: test first was normal in early days of programming • Famous as TDD since Kent Becks book in 2003
- 10. @PreusslerBerlin History • Started withtest first from XP in 1999 by Kent Beck • Just a rediscovery: test first was normal in early days of programming • Famous as TDD since Kent Becks book in 2003
- 11. @PreusslerBerlin History • Started withtest first from XP in 1999 by Kent Beck • Just a rediscovery: test first was normal in early days of programming • Famous as TDD since Kent Becks book in 2003
- 12.
- 13. @PreusslerBerlin The 3 rulesof TDD • You must write a failing test before you write any production code. • You must not write more of a test than is sufficient to fail, or fail to compile. • You must not write more production code than is sufficient to make the currently failing test pass. nano-cycle (seconds)
- 14. @PreusslerBerlin The 3 rulesof TDD • You must write a failing test before you write any production code. • You must not write more of a test than is sufficient to fail, or fail to compile. • You must not write more production code than is sufficient to make the currently failing test pass. nano-cycle (seconds)
- 15. @PreusslerBerlin The 3 rulesof TDD • You must write a failing test before you write any production code. • You must not write more of a test than is sufficient to fail, or fail to compile. • You must not write more production code than is sufficient to make the currently failing test pass. nano-cycle (seconds)
- 16. @PreusslerBerlin Red Green Refactor •Make it fail • Make it work • Make it right micro-cycle (minutes)
- 17. @PreusslerBerlin Red Green Refactor •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. @PreusslerBerlin Red Green Refactor •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. @PreusslerBerlin Red Green Refactor •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.
- 21. @PreusslerBerlin 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
- 22. @PreusslerBerlin Red Green Refactor •You need red: • as no one tests the tests • In green: • Speed trumps design! • Make it dirty!
- 23. @PreusslerBerlin Red Green Refactor •Always be one step away from green bar
- 24. @PreusslerBerlin Red Green Refactor •Always be one step away from green bar • Think of new test-> write it down
- 25. @PreusslerBerlin Red Green Refactor •Always be one step away from green bar • Think of new test-> write it down • It’s getting ugly? -> write it down
- 26. @PreusslerBerlin Why? •YAGNI and KISSout of the box •No more over engineering •Test all business needs •Eliminate debugging •Minimize use of Android devices
- 27. @PreusslerBerlin Why? •It’s Gamification =fun •Small Changes -> Small PRs •Always know what’s next
- 28. @PreusslerBerlin Why? •Less stressful •Go homeany time •Interrupt any time •No need for “flow”
- 29.
- 30. @PreusslerBerlin Write the teststhat forces you to write the code you want to write
- 31.
- 32.
- 33.
- 34.
- 35.
- 36.
- 37.
- 38.
- 39.
- 40.
- 41. @PreusslerBerlin Write the teststhat forces you to write the code you want to write Tip: Create a list of tests on paper
- 42. @PreusslerBerlin It is okto delete tests!
- 43.
- 44. @PreusslerBerlin Isn’t it slow? Writingtests is slower than not writing tests. You’ll write at least as much test code as production code
- 45. @PreusslerBerlin Isn’t it slow? Writingtests is slower than not writing tests. You’ll write at least as much test code as production code
- 46. @PreusslerBerlin Isn’t it slow? Researchshows that TDD: adds 10%—30% on initial costs = longer to complete their projects
- 47. @PreusslerBerlin Isn’t it slow? Researchshows that TDD: • Reduces defect density by 60-90 % • Reduces production bug density by 40–80%
- 48. @PreusslerBerlin Isn’t it slow? WithoutTDD, you spend a few weeks writing code which mostly works and spend the next year "testing" and fixing many (but not all) of the bugs
- 49. @PreusslerBerlin Isn’t it slow? WithTDD, you spend a year writing code which actually works. Then you do final integration testing for a few weeks.
- 50. @PreusslerBerlin Isn’t it slow? •Single feature will take longer • Bugfixing phase is shorter • Debugging disappears • Ci finds bugs before tester does • Long term it’s much faster no more big rewrite
- 51.
- 52. @PreusslerBerlin val binding =mock<ActivityPrivacyPolicyBinding>() val tested = PrivacyPolicyActivity() @Nested inner class `When created` { @Test fun `sets viewmodel`() { tested.onCreate(null) verify(binding).viewModel = navigationViewModel } }
- 53. @PreusslerBerlin val binding =mock<ActivityPrivacyPolicyBinding>() val tested = PrivacyPolicyActivity() @Nested inner class `When created` { @Test fun `sets viewmodel`() { tested.onCreate(null) verify(binding).viewModel = navigationViewModel } }
- 54. @PreusslerBerlin val binding =mock<ActivityPrivacyPolicyBinding>() val tested = PrivacyPolicyActivity() @Nested inner class `When created` { @Test fun `sets viewmodel`() { tested.onCreate(null) verify(binding).viewModel = navigationViewModel } }
- 55. @PreusslerBerlin val binding =mock<ActivityPrivacyPolicyBinding>() val tested = PrivacyPolicyActivity() @Nested inner class `When created` { @Test fun `sets viewmodel`() { tested.onCreate(null) verify(binding).viewModel = navigationViewModel } }
- 56. @PreusslerBerlin val binding =mock<ActivityPrivacyPolicyBinding>() val tested = PrivacyPolicyActivity() @Nested inner class `When created` { @Test fun `sets viewmodel`() { tested.onCreate(null) verify(binding).viewModel = navigationViewModel } }
- 57. @PreusslerBerlin val binding =mock<ActivityPrivacyPolicyBinding>() val tested = PrivacyPolicyActivity() @Nested inner class `When created` { @Test fun `sets viewmodel`() { tested.onCreate(null) verify(binding).viewModel = navigationViewModel } } protected
- 58. @PreusslerBerlin package android.app fun Activity.onCreate(bundle:Bundle?) = this.onCreate(bundle) github.com/ dpreussler/android-tdd-utils
- 59. @PreusslerBerlin val binding =mock<ActivityPrivacyPolicyBinding>() val tested = PrivacyPolicyActivity() @Nested inner class `When created` { @Test fun `sets viewmodel`() { tested.onCreate(null) verify(binding).viewModel = navigationViewModel } } Does this work?
- 60. @PreusslerBerlin Android SDK undertest • Android classes can be loaded on JVM: build/generated/mockable-android-XX.jar • Removes finals and ALL the code!
- 61. @PreusslerBerlin Android SDK undertest • Empty methods with default return values android { … testOptions { unitTests.returnDefaultValues = true } -> no code will run
- 62. @PreusslerBerlin The problem ofv4… Activity • mockable.jar not existing for libraries, including support library L -> real code will run
- 63. @PreusslerBerlin The problem ofv4… Activity • Helper method fun <T : FragmentActivity> T.prepareForTest(): T { … whenever(supportFragmentManager).thenReturn(mockSupportFragmentManager) whenever(fragmentManager).thenReturn(mockFragmentManager) whenever(layoutInflater).thenReturn(mockLayoutInflater) }
- 64. @PreusslerBerlin val binding =mock<ActivityPrivacyPolicyBinding>() val tested = PrivacyPolicyActivity().prepareForTest() @Nested inner class `When created` { @Test fun `sets viewmodel`() { tested.onCreate(null) verify(binding).viewModel = navigationViewModel } }
- 65. @PreusslerBerlin val binding =mock<ActivityPrivacyPolicyBinding>() val tested = PrivacyPolicyActivity().prepareForTest() @Nested inner class `When created` { @Test fun `sets viewmodel`() { tested.onCreate(null) verify(binding).viewModel = navigationViewModel } }
- 66. @PreusslerBerlin @Nested inner class `Whenstarted` { @Test fun `forwards lifecylce to viewmodel`() { tested.onStart() verify(viewModel).onStart() } } 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)
- 67. @PreusslerBerlin fun Fragment.safeStart() { try{ onStart() }catch (e: NullPointerException) {} catch (e: IllegalStateException) {} } github.com/ dpreussler/android-tdd-utils
- 68.
- 69. @PreusslerBerlin Avoid activity andfragment code • Use life cycle aware components! override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) observeLifecycleIn(viewModel) } @OnLifecycleEvent(ON_START) fun onStart() { …. }
- 70. @PreusslerBerlin Avoid activity andfragment code • Testing android view classes are hard • So let’s make sure we don’t need to test them! Use the power of data binding
- 71.
- 72. @PreusslerBerlin Data binding… who isthe view? • Solves the one big android question once and for all XML
- 73. @PreusslerBerlin What’s left? • Activitiesneeds to be declared in manifest • Permissions for older devices
- 74.
- 75. @PreusslerBerlin What’s left? • Manifestvia lint lintOptions { check 'Registered' warningsAsErrors true } * Has issues with Gradle Plugin 3.0 and Kotlin
- 76. @PreusslerBerlin What’s left? • Zerotolerance policy very valuable
- 77. @PreusslerBerlin What’s left? • Getaccess to merged manifest and resources: testOptions { unitTests.includeAndroidResources = true } com/android/tools/ test_config.properties
- 78. @PreusslerBerlin Whats left? • UI:text size, button text…
- 79.
- 80. @PreusslerBerlin What about Espresso •need to be fast! fast feedback! • need to run continuously! Espresso can’t give any of those
- 81. @PreusslerBerlin What about Espresso •Test first? Yes! • TDD? No!
- 82.
- 83. @PreusslerBerlin Tired of issueslike java.lang.NullPointerException at org.robolectric.manifest.MetaData .init(MetaData.java:55) at org.robolectric.manifest.AndroidM anifest.initMetaData(AndroidManif est.java:377).... ? Sleepy by Tomas; flickr.com/photos/tma/2438467223; CC 2.0 Don’t spent more time fixing your test setup than fixing your app Sleepy by Tomas; flickr.com/photos/tma/2438467223; CC 2.0 Still valid?
- 84.
- 85.
- 86.
- 87. @PreusslerBerlin Robolectric 4 • Robolectricis just another “android device” when using Espresso like API • Not compatible with Junit5 • More stable now as of new API?! • Still slower!?
- 88. @PreusslerBerlin Robolectric 4 • Increasesfirst test run by 6-8 sec • With ActivityTestRule: 12-14 sec
- 89. @PreusslerBerlin SPEED! • Build speedis important • Test new features in separate module!
- 90. @PreusslerBerlin Limitations • Custom viewand animation code might get too hard
- 91.
- 92. @PreusslerBerlin What about architecture? •TDD does not replace Architecture and Design • Have a vision in your head • NO big up front design • Defer architecture decisions as long as possible
- 93. @PreusslerBerlin What about architecture? •TDD does not replace Architecture and Design • Have a vision in your head • NO big up front design • Defer architecture decisions as long as possible
- 94. @PreusslerBerlin What about architecture? •TDD does not replace Architecture and Design • Have a vision in your head • No big up front design • Defer architecture decisions as long as possible
- 95. @PreusslerBerlin What about architecture? •TDD does not replace Architecture and Design • Have a vision in your head • No big up front design • Defer architecture decisions as long as possible
- 96.
- 97. @PreusslerBerlin What about codecoverage In TDD 100% coverage is a side effect not a goal!
- 98.
- 99. @PreusslerBerlin What about mocking •Mocks make our tests flaky • Only mock your outside dependency (think of modules not classes)
- 100. @PreusslerBerlin What about mocking •Mocks make our tests flaky • Only mock your outside dependency (think of modules not classes)
- 101. @PreusslerBerlin What about mocking •TDD changes the way your tests will be: Test1 Test2 Class1 Class2 Class3 Test3
- 102. @PreusslerBerlin What about mocking •TDD changes the way your tests will be: Test1 Class1 Class2 Class3
- 103. @PreusslerBerlin What about mocking •TDD changes the way your tests will be: Test1 Class1
- 104. @PreusslerBerlin What about mocking •TDD changes the way your tests will be: Test1 Class1 Class2 Class3
- 105. @PreusslerBerlin What about mocking •Tests will become more solid Test1 ViewModel Repository API
- 106. @PreusslerBerlin What about mocking •Tests will become more solid Test1 ViewModel Repository API Store Reducer SideEffects
- 107. @PreusslerBerlin What about mocking •Tests will become more solid Test1 ViewModel Repository API Store Reducer SideEffects
- 108. @PreusslerBerlin What about mocking •Mock your outside dependency (modules) Test1 ViewModel Repository API Store Reducer SideEffects
- 109. @PreusslerBerlin That’s not a UNITtest!? Test1 Class1 Class2 Class3
- 110. @PreusslerBerlin 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
- 111. @PreusslerBerlin 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
- 112. @PreusslerBerlin 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
- 113. @PreusslerBerlin 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
- 114.
- 115. @PreusslerBerlin What about Prototypes? hackingis fine but afterwards start from scratch!
- 116.
- 117. @PreusslerBerlin What about MVP? MVPis a minimum feature set but no excuse for bad quality
- 118. @PreusslerBerlin "Test only ifyou would want it to work.” Kent Beck
- 119. @PreusslerBerlin If it's worthbuilding, it's worth testing If it's not worth testing, why are you wasting your time working on it?
- 120. @PreusslerBerlin If it's worthbuilding, it's worth testing If it's not worth testing, why are you wasting your time working on it?
- 121. @PreusslerBerlin TDD on Android? •Its possible! • Might feel extreme • But it’s fun! https://www.flickr.com/photos/chefranden/14838138493
- 122. More resources • TestDriven Development by Example (Kent Beck) • TDD what went wrong: https://www.youtube.com/watch?v=EZ05e7EMOLM • The three laws of TDD by Uncle Bob https://www.youtube.com/watch?time_continue=1 7&v=AoIfc5NwRks • https://cleancoders.com/videos
- 123. 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 • github.com/dpreussler/android-tdd-utils
- 124. @PreusslerBerlin sporttotal.tv • We arestreaming under-medialised sports • Looking for Backend/Frontend/iOS Developer Designer (Cologne, Berlin)
- 125.