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

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 

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

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 

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

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 

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 

Specta • Similar to Kiwi using the RSpec BDD syntax but more of a customizable shell for writing tests than a drop-in replacement 8 

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

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

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

The pyramid • WeatherResultsViewController • WeatherService • LocationEntryViewController 12 

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 

15 

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 

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 

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 

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 

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 

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

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

24 

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 

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 

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

28