"TDD and mobile development: some forgotten techniques, illustrated with Android" by Matteo Vaccari
Delivering updates with confidence; shortening time to market; writing clean and correct code every day: this is the promise of Test-Driven Development. But, it’s not easy to do TDD in Android. You have to run the tests on the device, or install a complex framework that mimics the Android APIs. Both options slow you down. In this session we’ll get back to the roots of TDD and show how to deal with this problem. We’ll learn time-tested techniques that reduce the need to run tests on the device. The good side-effect is that our code becomes simpler and better.
14. Bureaucratic tests
1. Think a line of production code
2. Write a test that proves that the line of code exists
3. Write the line of code
4. .
15. Useful tests
1. Think a behaviour that I would like to have
2. Write a test that proves that the behaviour exists
3. Experiment ways to pass the test
4. $$$!………… Value !!!
22. fixing Gradle builds
is waste
and is not fun
How do you tell if an activity is value adding or waste?
Imagine doing that activity all the time… how does it feel?
What would the customer say if you do it all the time?
33. Very easy to test
public class UnitDoctorTest {
@Test
public void convertsInchesToCentimeters() {
UnitDoctor unitDoctor = new UnitDoctor();
assertEquals("2.54", unitDoctor.convert("1", "in", "cm"));
}
}
34. Yes yes… but my app
interacts heavily with
Android widgets!
35. Presenter-First
public class UnitDoctorTest {
@Rule public JUnitRuleMockery context = new JUnitRuleMockery()
UnitDoctorView view = context.mock(UnitDoctorView.class);
UnitDoctor unitDoctor = new UnitDoctor(view);
@Test
public void convertInchesToCm() throws Exception {
context.checking(new Expectations() {{
allowing(view).inputNumber(); will(returnValue(1.0));
allowing(view).fromUnit(); will(returnValue("in"));
allowing(view).toUnit(); will(returnValue("cm"));
oneOf(view).showResult(2.54);
}});
unitDoctor.convert();
}
36. What are mocks good for?
Mocking Android APIs?
Discovering interfaces ✅
37. Discover the “view” interface
public interface UnitDoctorView {
double inputNumber();
String fromUnit();
String toUnit();
void showResult(double result);
}
38. Presenter-First
public class UnitDoctorTest {
@Rule public JUnitRuleMockery context = new JUnitRuleMockery()
UnitDoctorView view = context.mock(UnitDoctorView.class);
UnitDoctor unitDoctor = new UnitDoctor(view);
@Test
public void convertInchesToCm() throws Exception {
context.checking(new Expectations() {{
allowing(view).inputNumber(); will(returnValue(1.0));
allowing(view).fromUnit(); will(returnValue("in"));
allowing(view).toUnit(); will(returnValue("cm"));
oneOf(view).showResult(2.54);
}});
unitDoctor.convert();
}
42. Yes, yes, yes… but my
app interacts heavily with
Android APIs!
43.
44. Acceptance tests
• Single touch. Dragging the finger should produce
a colored trail that fades to nothing
• Two touches. Dragging two fingers should
produce two decaying trails
• Multi-touch dashes. Draw a pattern like
—— —-— —-—
———————————
56. public interface CoreMotionEvent {
int getAction();
int getPointerCount();
int getPointerId(int pointerIndex);
void getPointerCoords(int pointerIndex, CorePoint outPointerCoords);
}
// Constants copied from android.view.MotionEven
static final int ACTION_DOWN = 0;
static final int ACTION_UP = 1;
static final int ACTION_MOVE = 2;
static final int ACTION_CANCEL = 3;
static final int ACTION_POINTER_DOWN = 5;
static final int ACTION_POINTER_UP = 6;
60. References
TDD For Android book (unfinished!) leanpub.com/tddforandroid
Source code for examples: github.com/xpmatteo
These slides are on slideshare.net/xpmatteo
Learn OOP and TDD well:
Growing Object-Oriented Software, Nat Pryce and Steve Freeman
TDD By Example, Kent Beck
Applying UML and Patterns, Craig Larman
61. Credits
• Carlo Bellettini was my sparring partner for this work
• The motto “Deliver valuable software faster, sustainably” is
my elaboration on Dan North’s “The goal of software
delivery is to minimise the lead time to business impact.
Everything else is detail.” I advise to attend one of Dan’s
seminars. They are illuminating.
• The “Fairy Fingers” idea is from “Ribbons” by Carlo Pescio
(www.aspectroid.com)
• The “gravity test” example is derived from a presentation
by Diego Torres Milano