Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Climbing the Testing Pyramid in iOS

Climbing the Testing Pyramid in iOS

Walk through building an iOS app that has well-tested business logic, service integration, and UI. To get maximum test coverage, we’ll demonstrate the tests that are most appropriate for each level of your app. Review the testing frameworks available for Objective-C and Swift and show you how to get them up and running so you can quickly add tests to your app.


Chris Trevarthen

May 30, 2015


  1. Climbing the Testing Pyramid in iOS Chris Trevarthen (@malusman) &

    Jake Payton (@JakePayton) https://github.com/ctrevarthen/selfconf-wunderground-objc 1
  2. Why test • Contract with your code / spec •

    Assists in refactoring • Documents code • Saves you time that you don’t have • In the future, where we are from, it is seen as malpractice not to test 2
  3. The pyramid • Functional UI • Service Integration • Unit

    Tests 3
  4. Questions • What about TDD? Do I have to test

    first? • What about test coverage? What should our goal be? • How much longer does it take? How do I get time to do this? • Why do I need QA? • Why can’t I just write all Functional tests? What’s the right mix of tests? • Test Ice Cream Cone is bad m’kay 4
  5. Unit Tests • Lots of options • Differences in output?

    • How it plays with Xcode • Advantages/ Disadvantages 5
  6. XCTest • Apple’s thing • Style of the tests aren't

    as sexy, but it plays very nice with Xcode. (i.e. run individual tests) • Performance Testing is supported, kinda neat (measureBlock) 6
  7. Kiwi • Pretty syntax, based on ruby RSpec style •

    great options for mocking, stubbing, spying, etc • Doesn't play as nice as XCTest in xCode, can’t run individual tests BUT you can run individual test suites with ⌘ + option + control + U • Derived Data 7
  8. Specta • Similar to Kiwi using the RSpec BDD syntax

    but more of a customizable shell for writing tests than a drop-in replacement 8
  9. Quick • Testing framework for Swift language • Similar to

    RSpec style test, uses Nimble for matching 9
  10. iOS testing is hard • To explain • Easier to

    show • Here’s an app we’ll add tests to 10
  11. Sunny Daze • Simple app functionality • Takes user input

    • Makes API calls • Extracts info • Displays info to user 11
  12. The pyramid • WeatherResultsViewController • WeatherService • LocationEntryViewController 12

  13. <CODEY BITS> 13

  14. How to write brittle tests • Test implementation • Rely

    on outside state • Test strings that will change • Real network calls • How to make tests less brittle - stubbing/mocking 14
  15. <CODEY BITS> 15

  16. Customizing your unit test framework • Can be further customized

    with these add-on libraries for mocking, stubbing, etc. • Idea here is that there are lots of ways to make testing work best for you 16
  17. Integration Tests • No special framework here, just an approach.

    • What you are testing is your ability to make requests and connections • You can use your preferred unit testing framework 17
  18. Integration Tests • But you will want to do these

    in a separate scheme so that you control when they occur • The are slow, expensive, and most likely talking to a real server which possible undesired outcomes • Tools like RunScope will test your endpoints regularly and send failure reports • OHHTTPStubs intercept network calls and injects your own data 18
  19. Functional Acceptance Tests • Most difficult to do, and keep

    doing • Testing the UI of your app and the resulting user experience • Works well to augment the manual testing by saving immense amounts of time and effort • Good for business/stakeholder to be able to define the test conditions in a human readable manner • User facing scenarios 19
  20. KIF • “Keep It Functional” • KIF-Kiwi • Or is

    it Kiwi-KIF? • "tap this view," "enter text into this view," and "wait for this view” 20
  21. <CODEY BITS> 21

  22. KIF • Can run right in Xcode • Need to

    manually clean up between tests • Good solution for Devs • Beware Xcode 6.3.x 22
  23. Frank / Calabash • Uses cucumber • “Features” are written

    in plain English • “Steps” are written in Ruby • (Supposedly) reusable across platforms 23
  24. <CODEY BITS> 24

  25. Frank / Calabash • Build-to-test cycle is disconnected • Good

    solution for BA/QA (with Dev help) • Cleans up between tests (slower) • Beware Xcode 6.3.x 25
  26. UIAutomation* • UIAutomation • Apple’s thing • Subliminal • XCTest/OCTest

    wrapper for UIAutomation • Appium • Uses Selenium’s WebDriver • Write tests in PHP, Java, Ruby, Node.js 26
  27. Serving Suggestion • Functional UI: 10% • Service Integration 20%

    • Unit Tests 70% 27
  28. 28