Slides by Wade Mealing

1. CodeAndroid Meetup
– Learning about the Platform
IE Singapore – The Little Red Dot
30th May 2009
10 AM
7/25/09

2. CodeAndroid meet up
Test Driven
Development
7/25/09

3. Objectives
Understand the basics of unit testing
Create a unit test.
Run the unit test on the emulator.
7/25/09

4. Apologies upfront:
Easily excited
Talk fast
Australian accent
Large area to explain
Questions, Slow down
7/25/09

5. Today:
Unit Testing
7/25/09

6. “The fundamental problem with
program maintenance is
that fixing a defect has a
substantial (20­50 %) chance of
introducing another defect.”
Mythical Man Month
7/25/09

7. Unit Testing is intended to:
verify software behavior
7/25/09

8. Unit Testing is intended to:
verify software behavior
using software
7/25/09

9. Independent code
that test or verify
larger sections of code
7/25/09

10. Software developers are
quite often :-
Developers
7/25/09

11. Software developers are
quite often :-
Developers
Testers
7/25/09

12. Software developers are
quite often :-
Developers
Testers
Quality Assurance
7/25/09

13. Software developers are
quite often :-
Developers
Testers
Quality Assurance
Documentation
7/25/09

14. Software developers are
quite often :-
Developers
Testers
Quality Assurance
Documentation
Support
7/25/09

15. Software developers are
quite often :-
Developers
Testers
Quality Assurance
Documentation
Support
Ninjas
7/25/09

16. If you are going to have to
do it anyway...
Why not automate it ?
7/25/09

17. You're thinking
“I already spend all day
coding!”
7/25/09

18. But
7/25/09

19. Unit testing reduces
issues created during
development and
maintenance
7/25/09

20. Yes, you will end up
writing more code
during development.
7/25/09

21. Why more code ?
Design
Facilitates change
Simplifies integration
Documentation
7/25/09

22. Design
The “API”
Specifies form and behavior
without internal details
Adequate “coverage” of the
API allows confidence in code
changes
7/25/09

23. Facilitate Change
Confidence in refactoring code
quickly.
Determine original functions work
when new features are added.
Verifiable tests take away guess
work when changing code.
7/25/09

24. Simpler Integration
Third party libraries can be
“swapped” with minimal pain.
Upgrades and dependencies can
be changed and proven.
Third parties can be held
responsible for their bugs.
7/25/09

25. Documentation
Tests may not explain why your
code works, but it shows how you
expect it to.
Tests meta data can be used to
supplement existing documents.
A form of “knowledge” transfer for
new team members.
7/25/09

26. “The fundamental problem with
program maintenance is
that fixing a defect has a
substantial (20­50 %) chance of
introducing another defect.”
Mythical Man Month
7/25/09

27. “The fundamental problem with
program maintenance is
that fixing a defect has a
substantial (20­50 %) chance of
introducing another defect.”
Mythical Man Month
7/25/09

28. Maintenance “cost” is
less.
7/25/09

29. Nobody can agree on the
cost of software
maintenance.
7/25/09

30. You will never catch all
bugs.
7/25/09

31. Adequate test coverage
will catch the nasty ones.
7/25/09

32. Testing wont improve
your code.
7/25/09

33. But the code you create
will have less surprises
7/25/09

34. Testing on Android
7/25/09

35. If you read this, you
survived the live
demonstration.
7/25/09

36. Additional information
in samples apiDemos
7/25/09

37. CodeAndroid.org
• Android Developer/User Group
• Grassroots effort by developers
• Promote Android development around this region (SEA,
Oceania)
• You can join us on Facebook, Twitter (codeandroid), IRC
(#codeandroid @ irc.freenode.net)
Special thanks to Google for the venue and food.
7/25/09

38. “The fundamental problem with
program maintenance is
that fixing a defect has a
substantial (20­50 %) chance of
introducing another defect.”
Mythical Man Month
7/25/09