12. How to test
1. Using support libraries
2. Stub code we can’t control while testing
3. Decoupled code
4. Testing everything that could be error-prone
13. How to test
1. Using support libraries
2. Stub code we can’t control while testing
3. Decoupled code
4. Testing everything that could be error-prone
16. Instrumentation
This framework monitors all of the interaction
between the Android system and the
application.
Android testing libraries are built on top of the
Instrumentation framework.
18. AndroidJUnitRunner
JUnit test runner that lets you run JUnit 3 or JUnit 4-style
test classes on Android devices, including those using the
Espresso and UI Automator testing frameworks.
The test runner handles loading your test package and the
app under test to a device, running your tests, and
reporting test results.
20. Espresso
APIs for writing UI tests to simulate user interactions within
a single target app.
Provides automatic sync of test actions with the app’s UI.
22. UI Automator
This framework provides a set of APIs to build UI tests that
perform interactions on user apps and system apps.
The UI Automator APIs allows you to perform operations
such as opening the Settings menu or the app launcher in a
test device.
23. How to test
1. Using support libraries
2. Stub code we can’t control while testing
3. Decoupled code
4. Testing everything that could be error-prone
24. Stub code we can’t control with testing
1. Robospice
2. Card reader
3. Thermal printer SDK
4. Bluetooth
25. How to test
1. Using support libraries
2. Stub code we can’t control while testing
3. Decoupled code
4. Testing everything that could be error-prone
26. Decoupled code
1. Android components only in charge of
lifecycle
2. Layer for business logic
3. Layer modeling views
4. Create utilities for code that can be unit
tested
27. How to test
1. Using support libraries
2. Stub code we can’t control while testing
3. Decoupled code
4. Testing everything that could be error-prone
28. Testing everything that could be error-prone
1. Do not test getter/setters
2. Test code created by us
3. Do not test third-party code (stub it or let it
be)
33. jUnit
Unit test
private EmailValidator subject = new EmailValidator();
@Test
public void doesNotValidateWithInvalidEmail() {
String email = "invalidEmail";
assertThat(subject.isValid(email), is(false));
}
34. jUnit + Instrumentation
Unit test
// This component uses the Android framework out of our control so we need to use instrumentation to provide a context
private CurrentUserSessionService subject = new CurrentUserSessionService(InstrumentationRegistry.
getTargetContext());
@Test
public void isCurrentSessionPresentReturnsTrueWithCurrentUser() {
subject.saveUserSession(buildUserSession());
assertThat(subject.isCurrentSessionPresent(), is(true));
}
private UserSession buildUserSession() {
// creates stub user session instance
}
67. Android
Components
Utilities
Android system
UI
Stubs
Espresso to manipulate and unit-
test views in an isolated Activity
Using manual or library-assisted dependency injection to
switch dependencies for stubs when testing
Unit testing
● jUnit
● Instrumentation
68. Android
Components
Utilities
Android system
UI
Stubs
Espresso to manipulate and unit-
test views in an isolated Activity
UI automator
Functional test of interactions
between the app and the Android
system
Using manual or library-assisted dependency injection to
switch dependencies for stubs when testing
Unit testing
● jUnit
● Instrumentation
69. Android
Components
Utilities
Android system
UI
Stubs
Espresso to manipulate and unit-
test views in an isolated Activity
Functional testing
● Espresso
● Espresso Intents
● Instrumentation
● Stubs
UI automator
Functional test of interactions
between the app and the Android
system
Using manual or library-assisted dependency injection to
switch dependencies for stubs when testing
Unit testing
● jUnit
● Instrumentation
70. ...then 2 + 2 = 4 so...
We can test on Android!
