1. Tests, Stubs, Mocks
 Effective Unittesting for
android

2. Goals of test automation
 Improve quality
 Understand the SUT
 Reduce the risk
 Easy to run
 Easy to write
 Easy to maintain
Subject
Under
Test

3. Principles in test automation
 Write the test first.
 Each test should be:
– Small and simple
– Independent to other test
– Repeatable
– Self-checking  Fully Automated
 First do “State verification”
and then “Behavior Verification”.

4. Which part can be automated?

5. System Under Test
 It may have Depended-on components
Image From: xunit Test Patterns, G. Meszaros

6. What are we talking about?
 Pattern: Test Double
 Also known as: Imposter
 Problem: How can we verify logic
independently when code it depends
on is unusable? How can we avoid
Slow Tests?
 Solution: We replace a component on
which the SUT depends with a "test-
specific equivalent."

7. WHAT?
Test Doubles:
 Dummy Object: Temporary Object that does not influence the SUT
 Test Stub: Hand coded object used for testing
 Test Spy: Verification occurs after the test method has been called
 Mock Object: Expectations configured before calling tests
 Fake Object: Typically, it implements the same functionality as the real
DOC but in a much simpler way, no expectation are configured.

8. Mock? Why?
 Mock - a simulated object that
mimics the behavior of a real
object in controlled ways.

9. Four phase testing
Image From: xunit Test Patterns, G. Meszaros

10. Test structure
Setup
Execute
Verify

11. Effective test automation
 After test generation by considering all
paths and the features and
organization specified, our test still
may have these bad smells:
– Slow Tests
– Test Code Duplication
– Obscure Tests
– Buggy Tests

12. Image SRC: www.dilbert.com

13. Mockito, how to drink it? framework basics
import static org.mockito.Mockito.*;
//mock creation
LinkedList mockedList = mock(LinkedList.class);
//using mock object
mockedList.add("one");
mockedList.clear();
//verification
verify(mockedList).add("one");
verify(mockedList).clear();
Stub - Mockito can
mock concrete
classes, not only
interfaces

14. Mockito, how to drink it? framework basics
 Return value thenReturn()
when(mock.someMethod("some
arg")).thenReturn("foo");
 Stubbing voids requires doReturn()
doReturn("bar").when(mock).foo();

15. What else to use
 PowerMock (private, final,static
methods)
 Jmockit (constructors and static
methods mocking)
 Hamcrest (library of matcher objects
(also known as constraints or
predicates) allowing 'match' rules to be
defined declaratively)

16. ANDROID UNIT TESTING

17. EXAMPLE: JUNIT + ROBOLECTRIC for Android
 Android unit testing is tricky:
– android.jar only contains mocked out .class
files which leads to
java.lang.RuntimeException: Stub!
 TIPS:
– Keep things simple by trying to make as many
services as possible not dependent on the
parts of the Android platform that are not
compatible with a conventional JVM.
– Robolectric to the rescue

18. Unit test depending on Android api
@RunWith(RobolectricTestRunner.class)
public class PopularRoutesAdapterTest {
private PopularRoutesAdapter adapter;
@Before
public void setUp() {
adapter = new PopularRoutesAdapter(
Robolectric.buildActivity(Activity.class).create().get();
}
@Test
public void testAddItem() {
assertEquals(0, adapter.getCount());
adapter.addItem(new Route("Arnhem"));
assertEquals(1, adapter.getCount());
}
Special test runner
coming with
Robolectric
Activity class is
mocked by
Robolectric

19. General rules to remember
 Mock it outside your code
 If you cannot test your code -> then probably
you should change it ;) cause its badly
written
 Test first
 Only one concrete class , mock the rest
 Only mock your neirest neighbour (Law of
Demeter -> dont talk with strangers)
 Think ;) and then write

20. Robo-WTF
Robolectric
 Has Java
implementations of
class files for most of
the Android API
 Enables true
unittesting, being not
dependent on any
network, hardware,
device or database
Roboguice
 Guice for Robolectric
 Dependency Injection
based in Google Guice
 Code bases DI instead
of XML (like in Spring)

21. Deckard
 Combination of
– Gradle / Maven
– Robolectric
– Junit
 Example adds
– Roboguice
– Mockito

22. DEMO

23. Developers Not Writing Tests
 Symptoms:
– No tests can be found when you ask to see the
• unit tests for a task,
• customer tests for a User Story,
– Lack of clarity about what a user story or task really means
 Impact:
– Lack of safety net
– Lack of focus
 Possible Causes:
– Hard to Test Code?
– Not enough time?
– Don’t have the skills?
– Have been told not to?
– Don’t see the value?
Robolectric for
unittesting
Espresso for
scenario-testing

24. Resources
 https://github.com/ddoa/dea-code-
examples/android-deckard-unittest/
 http://pages.cpsc.ucalgary.ca/~maurer/upload
s/SENG515615F2007/XUnitTestPattern.ppt
 http://code.google.com/p/mockito/
 https://docs.google.com/presentation/d/1J0W
iFJI9wSkc3UMsNXYv8ixX5orjkYzduwyOalzEk
jU/embed?hl=pl&size=l#slide=id.p5