Ensuring The Happy Path - Mobile Dev + Test

Ensuring The Happy Path - Mobile Dev + Test

Is there anything worse than trying to fix that one small bug, declaring it fixed, and then realizing “the fix” caused another bug somewhere else in your app? And there it is, one more bug and you are at it again. The small voice in your head says if only you had automated tests. We know we should invest more in testing because it can save us headaches down the road. Josiah Mory says that although getting started can be an uphill climb, automated testing does not have to be all or nothing. Josiah introduces approaches for automating developer tests along with test-driven development and behavior-driven development methodologies. Even though Josiah shows real examples using Swift and iOS code implementations, the concepts he discusses apply to any software. Leave this session with an understanding of the benefits we get from testing, conversation points to advocate testing to co-workers and management, and practical ways of implementing automation and unit tests.

55e2e1f28b890e26c101ed44c5f1d3af?s=128

kickinbahk

June 20, 2017
Tweet

Transcript

  1. Ensuring the Happy Path @kickinbahk Josiah Mory

  2. This is Me

  3. New Feature

  4. Wait…but it worked before!?!

  5. Just need to fix this one last bug…

  6. None
  7. None
  8. None
  9. None
  10. Why Test?

  11. Rephrased: What are the benefits of testing?

  12. Check for Behavior

  13. Refactoring Assurance

  14. Doesn’t the Compiler Test Enough for us?

  15. The Compiler Checks for….

  16. Compile-Time Bugs

  17. Types (type of objects we place into functions)

  18. An object’s adherence to protocols

  19. Nil

  20. The compiler does not check for….

  21. Runtime errors

  22. Behavior

  23. Testing Takes Too Much Time

  24. TDD is SUPER Intense!

  25. None
  26. TDD Not Required

  27. 100% Coverage Not Required

  28. Testing doesn’t need to be all or nothing

  29. Start off just Testing Main Functionality

  30. Many 3rd Party Test Frameworks • Quick/Nimble • Kiwi •

    Specta • XCFit
  31. None
  32. None
  33. “But we don’t want to include (more) third party libraries”

  34. Enter XCTest Apple’s test framework built into Xcode

  35. None
  36. None
  37. TDD Doesn’t Fit our Business Model

  38. Time = Money

  39. Testing requires more modular code

  40. Less time spent in manual QA

  41. Less time Debugging and Fixing Programmer Errors

  42. Our users shouldn’t be our QA team

  43. Loss of confidence due to reoccurring bugs

  44. None
  45. Testing…

  46. covers a multitude of mistakes

  47. and provides refactoring reassurance

  48. Testing doesn’t need to be all or nothing

  49. Start off just Testing Main Functionality

  50. and continue adding tests as needed

  51. Thank you! @kickinbahk Josiah Mory