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
Tweet

More Decks by Chris Trevarthen

Other Decks in Technology

Transcript

  1. Climbing
    the Testing
    Pyramid in iOS
    Chris Trevarthen (@malusman)
    & Jake Payton (@JakePayton)
    https://github.com/ctrevarthen/selfconf-wunderground-objc
    1

    View full-size slide

  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

    View full-size slide

  3. The pyramid
    • Functional UI
    • Service Integration
    • Unit Tests
    3

    View full-size slide

  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

    View full-size slide

  5. Unit Tests
    • Lots of options
    • Differences in output?
    • How it plays with Xcode
    • Advantages/
    Disadvantages
    5

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  9. Quick
    • Testing framework for Swift language
    • Similar to RSpec style test, uses Nimble for
    matching
    9

    View full-size slide

  10. iOS testing is hard
    • To explain
    • Easier to show
    • Here’s an app we’ll add tests to
    10

    View full-size slide

  11. Sunny Daze
    • Simple app functionality
    • Takes user input
    • Makes API calls
    • Extracts info
    • Displays info to user
    11

    View full-size slide

  12. The pyramid
    • WeatherResultsViewController
    • WeatherService
    • LocationEntryViewController
    12

    View full-size slide

  13. 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

    View full-size slide

  14. 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

    View full-size slide

  15. 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

    View full-size slide

  16. 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

    View full-size slide

  17. 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

    View full-size slide

  18. 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

    View full-size slide

  19. KIF
    • Can run right in Xcode
    • Need to manually clean up
    between tests
    • Good solution for Devs
    • Beware Xcode 6.3.x
    22

    View full-size slide

  20. Frank / Calabash
    • Uses cucumber
    • “Features” are written in plain
    English
    • “Steps” are written in Ruby
    • (Supposedly) reusable across
    platforms
    23

    View full-size slide

  21. 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

    View full-size slide

  22. 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

    View full-size slide

  23. Serving Suggestion
    • Functional UI: 10%
    • Service Integration 20%
    • Unit Tests 70%
    27

    View full-size slide