We have all heard about TDD: Test Driven Development. It produces better code and leads to fewer bugs. But, in our daily Android lives, why aren’t we doing it? Is it possible to develop an Android app that is fully test driven? Where do you start? Should you only test Java classes? Should you use or avoid Robolectric?

1. TDD
on Android
Danny Preussler, Øredev 2018

2. @PreusslerBerlin
about:me
• Switched to Java in 2003
• Talking about testing on mobile since 2008
• Worked for eBay, Groupon, Viacom

3. @PreusslerBerlin
Let’s
talk about
tests

4. @PreusslerBerlin
“Code without tests is bad code.”
“any code without test is a legacy code.”
(Michael C. Feathers)

5. @PreusslerBerlin
“Code without tests is bad code.”
“any code without test is legacy code.”
(Michael C. Feathers)

6. @PreusslerBerlin
Tests give confidence
“how do you know something works when you
don’t have test for it?”
(Robert ‘Uncle Bob’ Martin)

7. @PreusslerBerlin
Tests allow refactoring
“Refactoring without good test coverage
is changing shit”
(Martin Fowler)

8. @PreusslerBerlin
TDD

9. @PreusslerBerlin
History
• Started with test 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 with test 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 with test 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. @PreusslerBerlin
How does
it work?

13. @PreusslerBerlin
The 3 rules of 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 rules of 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 rules of 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. @PreusslerBerlin
WTF
https://www.flickr.com/photos/jantruter/12794187835

21. @PreusslerBerlin
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

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 KISS out 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 home any time
•Interrupt any time
•No need for “flow”

29. @PreusslerBerlin
Start somewhere

30. @PreusslerBerlin
Write the tests that
forces you
to write the code
you want to write

31. @PreusslerBerlin
Start somewhere

32. @PreusslerBerlin
Start somewhere

33. @PreusslerBerlin
Start somewhere

34. @PreusslerBerlin
Start somewhere

35. @PreusslerBerlin
Start somewhere

36. @PreusslerBerlin
Start somewhere

37. @PreusslerBerlin
Start somewhere

38. @PreusslerBerlin
Start somewhere

39. @PreusslerBerlin
Start somewhere

40. @PreusslerBerlin
Start somewhere

41. @PreusslerBerlin
Write the tests that
forces you
to write the code
you want to write
Tip: Create a list of tests on paper

42. @PreusslerBerlin
It is ok to delete tests!

43. @PreusslerBerlin
Isn’t that
slow?
https://pixabay.com/en/snail-illustration-drawing-yellow-1757756/

44. @PreusslerBerlin
Isn’t it slow?
Writing tests is slower than not writing tests.
You’ll write at least as much test code as
production code

45. @PreusslerBerlin
Isn’t it slow?
Writing tests is slower than not writing tests.
You’ll write at least as much test code as
production code

46. @PreusslerBerlin
Isn’t it slow?
Research shows that TDD:
adds 10%—30% on initial costs
= longer to complete their projects

47. @PreusslerBerlin
Isn’t it slow?
Research shows that TDD:
• Reduces defect density by 60-90 %
• Reduces production bug density by 40–80%

48. @PreusslerBerlin
Isn’t it slow?
Without TDD, 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?
With TDD, 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. @PreusslerBerlin
Android
specifics

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 under test
• Android classes can be loaded on JVM:
build/generated/mockable-android-XX.jar
• Removes finals and ALL the code!

61. @PreusslerBerlin
Android SDK under test
• Empty methods with default return values
android {
…
testOptions {
unitTests.returnDefaultValues = true
}
-> no code will run

62. @PreusslerBerlin
The problem of v4… Activity
• mockable.jar not existing for libraries,
including support library L
-> real code will run

63. @PreusslerBerlin
The problem of v4… 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 `When started` {
@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. @PreusslerBerlin
Avoid
Activity/Fragment
code

69. @PreusslerBerlin
Avoid activity and fragment 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 and fragment 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. @PreusslerBerlin
Data binding…
XML ViewModelbind

72. @PreusslerBerlin
Data binding…
who is the view?
• Solves the one big android question once
and for all
XML

73. @PreusslerBerlin
What’s left?
• Activities needs to be declared in manifest
• Permissions for older devices

74. @PreusslerBerlin
What’s left?

75. @PreusslerBerlin
What’s left?
• Manifest via lint
lintOptions {
check 'Registered'
warningsAsErrors true
}
* Has issues with Gradle Plugin 3.0 and Kotlin

76. @PreusslerBerlin
What’s left?
• Zero tolerance policy very valuable

77. @PreusslerBerlin
What’s left?
• Get access 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. @PreusslerBerlin
What about
Espresso?

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. @PreusslerBerlin
What about
Robolectric?

83. @PreusslerBerlin
Tired of issues like
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. @PreusslerBerlin
Robolectric 4

85. @PreusslerBerlin
Robolectric 4

86. @PreusslerBerlin
Robolectric 4

87. @PreusslerBerlin
Robolectric 4
• Robolectric is 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
• Increases first test run by 6-8 sec
• With ActivityTestRule: 12-14 sec

89. @PreusslerBerlin
SPEED!
• Build speed is important
• Test new features in separate module!

90. @PreusslerBerlin
Limitations
• Custom view and animation code might get too
hard

91. @PreusslerBerlin
What
about
architecture
?

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. @PreusslerBerlin
What
about
code
coverage
?

97. @PreusslerBerlin
What about code coverage
In TDD
100% coverage
is a
side effect
not a goal!

98. @PreusslerBerlin
What
about
mocking
?

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 UNIT test!?
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. @PreusslerBerlin
What
about
protoypes
?

115. @PreusslerBerlin
What about Prototypes?
hacking is fine
but afterwards
start from scratch!

116. @PreusslerBerlin
What
about
MVP ?

117. @PreusslerBerlin
What about MVP?
MVP is a minimum feature
set but
no excuse for bad quality

118. @PreusslerBerlin
"Test only if you would
want it to work.”
Kent Beck

119. @PreusslerBerlin
If it's worth building,
it's worth testing
If it's not worth testing,
why are you wasting your time
working on it?

120. @PreusslerBerlin
If it's worth building,
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
• Test Driven 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 are streaming under-medialised sports
• Looking for
Backend/Frontend/iOS Developer Designer
(Cologne, Berlin)

125. TDD
on Android
@PreusslerBerlin