Practical Testing Tips - CocoaConf Chicago, March 2015

A smorgasboard of testing tips for iOS, in both Objective-C and Swift. Links are in the slides at the end of the deck.

Transcript

1. PRACTICAL TESTING TIPS by Ellen Shapiro | Cocoaconf Chicago 2015 vokal.io | justhum.com | designatednerd.com | @designatednerd
2. Why don't developers write tests?
3. "I Don't have time to Write tests"
4. Writing Tests lets you refactor faster and with more confidence
5. Writing tests puts your time costs up front
6. Writing tests catches your mistakes as you make them
7. "I must cover every conceivable scenario"
8. Don't let the perfect be the enemy of the good
9. "I Have No idea where to start"
10. What should you test?
11. Test The Stuff That Breaks A Lot
12. "That's called software."
13. Test The Stuff That is easier for a robot than for you to test
14. Your computer is an awesome robot you can use to do your evil bidding.
15. [ Demo: Time Converter 24 ]
16. Test The Stuff That is mission-critical
17. if it breaks, will your users do this?
18. [ Demo: Core data testing ]
19. Core Data Demo Recap » When you see somthing that can cause a key piece of your app to break » When testing core data, test the NSInMemoryStoreType so you always have a clean database. » Version your databases!
20. Test The Stuff That Depends On Someone Else
21. Is it my code? or Is it their code?
22. Test it with something that looks like the real thing.
23. Mock testing
24. Verifying Did this do what it was supposed to?
25. Stubbing Fake it 'til you make it
26. Spying Faking PART of an object
27. Objective-C Mocking tools OCMock OCMockito
28. [ Demo: Making a Mockery ]
29. Objective-C Mock Demo Recap » Make a fake thing » Tell it what to do » Pass it to the thing you want to test » Make sure the tested thing reacted properly
30. Mocking in swift
31. Swift Inline Class Verification func testThingDoesStuff() { class MockThing : Thing { var methodUnderTestWasCalled = false override func methodUnderTest() { //Don't call super! methodUnderTestWasCalled = true } } let testThing = new MockThing() testThing.doSomethingThatShouldCallMethodUnderTest() XCTAssertTrue(testThing.methodUnderTestWasCalled) }
32. Swift Inline Class Stubs/Spies func testThingDoesStuff() { class StubbedThing : Thing { override func methodBeingStubbed() -> String { //Don't call super! return "A Known String!" } } let stub = new StubbedThing() let tested = new ObjectUnderTest() objectUnderTest.thing = stubbed let result = tested.doSomethingThatEventuallyCallsMethodBeingStubbed() XCTAssertTrue(result == "A Known String!") }
33. Mocking Network Responses
34. ¡¡ Flagrant plug alert !!
35. VOKMockUrlProtocol for iOS Mocktrofit for Android open-source projects of Vokal, my employers
37. HTTP/1.1 200 OK Server: nginx/1.4.6 (Ubuntu) Date: Wed, 12 Nov 2014 22:10:40 GMT Content-Type: application/json Transfer-Encoding: chunked Connection: keep-alive Vary: Accept X-Frame-Options: SAMEORIGIN Allow: GET, PUT, PATCH, DELETE, HEAD, OPTIONS { "default": true, "expiration_month": "10", "expiration_year": "2018", "last_4": "1234", "card_type": "MasterCard", "id": 2 }
38. { "default": true, "expiration_month": "10", "expiration_year": "2018", "last_4": "1234", "card_type": "MasterCard", "id": 2 }
39. #import "VOKMockURLProtocol.h" @implementation CLTAPIClient (MockData) - (void)setShouldUseMockData:(BOOL)shouldUseMockData { Class mockURLProtocol = [VOKMockUrlProtocol class]; NSMutableArray *currentProtocolClasses = [self.sessionConfiguration.protocolClasses mutableCopy]; if (shouldUseMockData) { [currentProtocolClasses insertObject:mockURLProtocol atIndex:0]; } else { [currentProtocolClasses removeObject:mockURLProtocol]; } self.sessionConfiguration.protocolClasses = currentProtocolClasses; } @end
40. Test your networking logic and your UI against known data
41. Also Test it with the real thing
42. Know what you can depend on
43. Sometimes this can cause a big fight
44. You are at the mercy of your internet connection
45. Testing against a live server can change things
46. Testing against a live server can return different data if someone else changed something
47. Know the limits of what you can test live
48. Don't lock yourself out
49. Test that you're getting expected response types, not exact data
50. Test the things that aren't already covered
51. Code Coverage tools
52. Local code coverage » gcov » lcov » XcodeCoverage* » XCoverage * - I am a contributor
56. Remote code coverage Designed to work with Continuous Integration servers » codecov.io » coveralls.io
57. Swift code coverage ¯\_(
    )_/¯
58. "I must cover every single line of code"
59. The most useless test I ever inherited: [Note: class prefixes have been changed to protect the guilty]
60. focus on why something needs to be covered rather than whether it's covered
61. How do you write tests?
62. Test Driven Developlment
63. You have seen The TDD demo (and it has usually taken way too long)
64. The TL;DR version of the TDD demo
65. 1. Write a failing test LargerTest.m - (void)testLarger { NSInteger larger = [Larger largerOf:2 and:5]; XCTAssertEqual(larger, 5); } Larger.m + (NSInteger)largerOf:(NSInteger)one and:(NSInteger)another { return 0; }
66. 2. Write code to make it pass LargerTest.m - (void)testLarger { NSInteger larger = [Larger largerOf:2 and:5]; XCTAssertEqual(larger, 5); } Larger.m + (NSInteger)largerOf:(NSInteger)one and:(NSInteger)another { if (one > another) { return one; } else { return another; } }
67. 3-∞. Refactor, but now with the guardrails of the test LargerTest.m - (void)testLarger { NSInteger larger = [Larger largerOf:2 and:5]; XCTAssertEqual(larger, 5); } Larger.m + (NSInteger)largerOf:(NSInteger)one and:(NSInteger)another { return MAX(one, another); }
68. Repeat for every public method you write.
69. Behavior Driven Development
70. Same idea as TDD Different approach
71. Does it do what it's supposed to for the end user?
72. Given / When / Then
73. You can use libraries to enforce BDD Kiwi Specta Cedar
75. I personally prefer to use XCTest for non-UI tests
76. [ Demo: BDD in pure XCTest ]
77. BDD Demo Recap: » Use very descriptive test names. » Test the end result, not necessarily how you got there. » Use the XCTest methods you already know. » Use comments if you need the structure of given/ when/then.
78. UI Testing
79. KIF
80. Keep It Functional
81. Kif Pros » Write your UI tests in Objective C! » Uses Accessibility, so you make your app accessible in the bargain » Get to the bit you need to test » The most widely used library » Very backwards compatible
82. Kif Cons » Sloooooooooow » Some folks have had issues with lookup changing the view hierarchy » Very backwards compatible
83. [ Demo: Kif In Action ]
84. Testing your UI en muchos idiomas !"#$%&'()
85. [ Demo: Scheme Fun With Languages ]
86. UI Testing Recap » If you're swapping out your app delegate for tests, make sure you put it back for UI tests » Centralize your localized strings in a convenience class to make strings easier to test » UI and non-UI tests should be seperate targets » Add -AppleLanguages "\(en\)" arguments to the test bit of your application's scheme » Duplicate your scheme and update for every language you support
87. A Final word of warning
88. Tests do not and cannot catch everything
89. Remember: Humans use your application
90. Humans are weird
91. Humans multitask
92. Humans and Robots working together to break your app make your app better
93. Official Summary Slide™ » Testing lets you refactor more confidently, and find out immediately when you break stuff. » Test as much as you can, however much that is. » Find the testing ideology that works best for you. » UI Testing can give you a great opportunity to see how all the pieces of your app work together. » Have both humans and robots test your app for best results.
94. Questions?
95. Things from me or my employer! #humblebrag » https://github.com/designatednerd/ TestingPlayground » https://github.com/designatednerd/FlickrSearcher » https://github.com/designatednerd/ DNSiOSLocalizationTestHelpers » https://github.com/vokal/VOKMockUrlProtocol » https://github.com/vokal/Mocktrofit
96. Mocking tools! » http://ocmock.org/ » https://github.com/jonreid/OCMockito UI Testing Tools! » https://github.com/kif-framework/KIF » https://github.com/Raizlabs/FRY
97. Code Coverage Tools! » https://codecov.io/ » https://coveralls.io » https://github.com/jonreid/XcodeCoverage » https://github.com/dropbox/XCoverage » http://www.xcoverageapp.com/
98. BDD Tools! » https://github.com/specta/specta » https://github.com/kiwi-bdd/Kiwi » https://github.com/pivotal/cedar Other Things I Mentioned! » http://ntoll.org/article/tdd-cargo-cult » http://qualitycoding.org/app-delegate-for-tests/
99. Photo Credits » Angry mob by Robert Course-Baker: https:// www.flickr.com/photos/29233640@N07/3645211083 » Robot by Logan Ingalls: https://www.flickr.com/ photos/plutor/847695350 » Lock ("Hodgepodged") by David Goehring https:// www.flickr.com/photos/carbonnyc/4740626368/ » All images of Kif from Futurama used without permission. Sorry, Fox.