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.

6. TDD Brotherhood

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)

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

46. Tests tell a story

47. Tests tell a story

48. Tests tell a story • Test your behaviour • Think about your domain

49. What to mock?

51. What about mocking

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

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!

77. Data binding… XML ViewModel bind

78. Compose Composable ViewModel bind

79. What about Robolectric?

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

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

109. 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

114. Mark Seemann (https://blog.ploeh.dk/2019/03/18/the-programmer-as-decision-maker/)

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

Test Driven Development on Android (Kotlin Kenya)

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Test Driven Development on Android (Kotlin Kenya)

Similar to Test Driven Development on Android (Kotlin Kenya) (20)

More from Danny Preussler

More from Danny Preussler (17)

Recently uploaded

Recently uploaded (20)

Test Driven Development on Android (Kotlin Kenya)