Keeping Your Users Happy With Testable Apps

Given at Xamarin Evolve on April 16, 2013

Transcript

1. Greg Shackles OLO @gshackles greg@gregshackles.com github.com/gshackles Keeping Your Users Happy With Testable Apps
2. TDD
3. TDD KISS SOLID BDD DRY SOC YAGNI DDD SRP OCP LSP ISP DIP XP IOC CQS
5. Why Test?
6. Stability
7. Stability • Obvious, but important
8. Stability • Obvious, but important • Refactor and iterate with a safety net
9. Stability • Obvious, but important • Refactor and iterate with a safety net • Compilation is only the first unit test
10. Stability • Obvious, but important • Refactor and iterate with a safety net • Compilation is only the first unit test • Verify cross-platform compatibility
11. “I don’t have time to write tests!”
12. “I don’t have time to NOT write tests!”
13. Once It’s Out, It’s Out
14. Once It’s Out, It’s Out • This isn’t the web
15. Once It’s Out, It’s Out • This isn’t the web • Difficult and expensive to fix
16. Once It’s Out, It’s Out • This isn’t the web • Difficult and expensive to fix • Quality bar has been raised
17. Once It’s Out, It’s Out • This isn’t the web • Difficult and expensive to fix • Quality bar has been raised • Bad reviews stick with you
18. The Happy Path
19. • Improves design The Happy Path
20. • Improves design • More shared code (not just mobile apps) The Happy Path
21. • Improves design • More shared code (not just mobile apps) • Optimize independently of a platform The Happy Path
22. • Improves design • More shared code (not just mobile apps) • Optimize independently of a platform • IterationSpeed++ The Happy Path
23. • Improves design • More shared code (not just mobile apps) • Optimize independently of a platform • IterationSpeed++ • FACT: Green tests are good for the soul The Happy Path
24. What To Test?
25. What to Test?
26. What to Test? • 100% code coverage != the goal
27. What to Test? • 100% code coverage != the goal • Test parts that provide value
28. What to Test? • 100% code coverage != the goal • Test parts that provide value • Testing platform code can be difficult
29. What to Test? • 100% code coverage != the goal • Test parts that provide value • Testing platform code can be difficult • Start small
31. ! ! Unit  Tests
32. ! ! ! ! Unit  Tests Integra-on  Tests
33. ! ! ! ! ! ! Unit  Tests Integra-on  Tests UI  /  UX  Tests
34. ! ! ! ! ! ! Unit  Tests Integra-on  Tests UI  /  UX  Tests Mixed Automated
35. Unit / Integration Tests
36. Unit / Integration Tests • Automated
37. Unit / Integration Tests • Automated • Low friction
38. Unit / Integration Tests • Automated • Low friction • Leverage tooling
39. Unit / Integration Tests • Automated • Low friction • Leverage tooling • NUnit (Lite)
40. Unit / Integration Tests • Automated • Low friction • Leverage tooling • NUnit (Lite) • Run on all platforms
41. Unit / Integration Tests • Automated • Low friction • Leverage tooling • NUnit (Lite) • Run on all platforms • Simulator vs Device
42. Mocking
43. Mocking • Limited options
44. Mocking • Limited options • Manual mocking
45. Mocking • Limited options • Manual mocking • Code generation, T4 github.com/gshackles/Muntz
46. 01 02 03 04 05 06 07 08 09 10 11 12 13 14 Mocking interface IService { ! string Foo(string bar); } ! class MockService : IService { ! public Func<string> FooBody { get; set; } ! ! ! public Foo(string bar) ! { ! ! return FooBody(); ! } }
47. Manual Testing
48. Manual Testing • User feedback is critical
49. Manual Testing • User feedback is critical • UX testing
50. Manual Testing • User feedback is critical • UX testing • Exploratory testing
51. Manual Testing • User feedback is critical • UX testing • Exploratory testing • TestFlight testflightapp.com
52. MVVM
53. MVVM • MvvmCross
54. MVVM • MvvmCross • Shared, testable view models
55. MVVM • MvvmCross • Shared, testable view models • Improved IoC support
56. MVVM • MvvmCross • Shared, testable view models • Improved IoC support • Databinding keeps views thin
57. DEMO
58. Q&A