iOS testing
5 likes1,618 views
This document discusses testing in iOS applications. It begins by introducing the author and their background. It then discusses reasons for testing like reliability, regression testing, and confidence during refactoring. Potential issues with testing like heavy UI dependence and non-testable code are addressed. The document recommends separating UI and service code for better testability. It demonstrates the Kiwi and OCMock testing frameworks and provides examples of testing classes, dependencies, and private/static methods in an isolated way without heavy mocking. It emphasizes best practices like writing tests first and using version control properly.
![Kiwi
describe(@"Tested class", ^{
context(@"When created", ^{
it(@"should not fail", ^{
[[theValue(0) should] equal:theValue(0)];
});
});
});](https://image.slidesharecdn.com/iostesting-130112095816-phpapp02/85/iOS-testing-17-320.jpg)
![Kiwi
describe(@"Tested class", ^{
context(@"When created", ^{
it(@"should not fail", ^{
id viewController = [ViewController new];
[[viewController should]
conformToProtocol:@protocol(UITableViewDelegate)];
});
});
});](https://image.slidesharecdn.com/iostesting-130112095816-phpapp02/85/iOS-testing-18-320.jpg)
![Matchers
[subject
shouldNotBeNil]
• [subject
shouldBeNil]
• [[subject
should]
beIdenticalTo:(id)anObject] - compares id's
• [[subject
should]
equal:(id)anObject]
• [[subject
should]
equal:(double)aValue
withDelta:
(double)aDelta]
• [[subject
should]
beWithin:(id)aDistance
of:(id)aValue]
• [[subject
should]
beLessThan:(id)aValue]
• etc.
etc.](https://image.slidesharecdn.com/iostesting-130112095816-phpapp02/85/iOS-testing-19-320.jpg)
![Compare to SenTesting Kit
[[subject
should]
equal:anObject]
compare
with
STAssertEquals(subject,
anObject,
@”Should
be
equal”);](https://image.slidesharecdn.com/iostesting-130112095816-phpapp02/85/iOS-testing-20-320.jpg)
![Classic calculator sample
describe(@"Calculator",
^{
context(@"with
the
numbers
60
and
5
entered",
^{
RPNCalculator
*calculator
=
[[RPNCalculator
alloc]
init];
beforeEach(^{
[calculator
enter:60];
[calculator
enter:5];
});
afterEach(^{
[calculator
clear];
});
it(@"returns
65
as
the
sum",
^{
[[theValue([calculator
add])
should]
equal:65
withDelta:.01];
});](https://image.slidesharecdn.com/iostesting-130112095816-phpapp02/85/iOS-testing-23-320.jpg)
![Test dependency
// Create the tested object and mock to exchange part of the functionality
viewController = [ViewController new];
mockController = [OCMockObject partialMockForObject:viewController];
// Create the mock and change implementation to return our class
id serviceMock = [OCMockObject mockForClass:[InterwebzService class]];
[[[mockController stub] andReturn:serviceMock] service];
// Define expectations
[[serviceMock expect] downloadTweetsJSONWithSuccessBlock:[OCMArg any]];
// Run the tested method
[viewController tweetsButtonTapped:nil];
// Verify - throws exception on failure
[mockController verify];](https://image.slidesharecdn.com/iostesting-130112095816-phpapp02/85/iOS-testing-25-320.jpg)
![Accessing private methods
@interface ViewController()
- (void)startDownloadingTweets;
@end
...
[[mockController expect] startDownloadingTweets];](https://image.slidesharecdn.com/iostesting-130112095816-phpapp02/85/iOS-testing-28-320.jpg)
![Static method testing
• Through separation to a method
@interface ViewController()
- (NSUserDefaults *)userDefaults;
@end
...
id mockDefaults = [OCMockObject mockForClass:[NSUserDefaults class]];
[[[mockDefaults expect] andReturn:@"Setting"] valueForKey:[OCMArg any]];
[[[mockController stub] andReturn:mockDefaults] userDefaults];](https://image.slidesharecdn.com/iostesting-130112095816-phpapp02/85/iOS-testing-29-320.jpg)
iOS testing
- 1. Testing in iOS 10.01.2013 by Tomasz Janeczko
- 2. About me Tomasz Janeczko • iOS developer in Kainos • Enthusiast of business, electronics, Rails & Heroku • Organizer of first App Camp in UK and PL
- 3. So let’s talk about testing.
- 4. Why we test?
- 6. So?
- 7. • Reliability • Regression • Confidence (e.g. refactoring)
- 8. Why not to test?
- 9. Why not to test? • Heavy dependence on UI • Non-testable code • Bad framework
- 10. How to address issues • Sample - downloading stuff from interwebz
- 11. First fault Writing tests after writing code
- 13. Separation of concerns • Let’s separate out the UI code • Same for services interaction
- 14. Demo of tests
- 15. Writing tests Meet Kiwi and OCMock
- 16. Kiwi • RSpec-like tests writing • Matchers • Cleaner and more self-descriptive code
- 17. Kiwi describe(@"Tested class", ^{ context(@"When created", ^{ it(@"should not fail", ^{ [[theValue(0) should] equal:theValue(0)]; }); }); });
- 18. Kiwi describe(@"Tested class", ^{ context(@"When created", ^{ it(@"should not fail", ^{ id viewController = [ViewController new]; [[viewController should] conformToProtocol:@protocol(UITableViewDelegate)]; }); }); });
- 19. Matchers [subject shouldNotBeNil] • [subject shouldBeNil] • [[subject should] beIdenticalTo:(id)anObject] - compares id's • [[subject should] equal:(id)anObject] • [[subject should] equal:(double)aValue withDelta: (double)aDelta] • [[subject should] beWithin:(id)aDistance of:(id)aValue] • [[subject should] beLessThan:(id)aValue] • etc. etc.
- 20. Compare to SenTesting Kit [[subject should] equal:anObject] compare with STAssertEquals(subject, anObject, @”Should be equal”);
- 21. OCMock • Mocking and stubbing library for iOS • Quite versatile • Makes use of NSProxy magic
- 22. Sample workflows
- 23. Classic calculator sample describe(@"Calculator", ^{ context(@"with the numbers 60 and 5 entered", ^{ RPNCalculator *calculator = [[RPNCalculator alloc] init]; beforeEach(^{ [calculator enter:60]; [calculator enter:5]; }); afterEach(^{ [calculator clear]; }); it(@"returns 65 as the sum", ^{ [[theValue([calculator add]) should] equal:65 withDelta:.01]; });
- 24. Test if calls dep methods 1. Create a mock dependency 2. Inject it 3. Call the method 4. Verify
- 25. Test dependency // Create the tested object and mock to exchange part of the functionality viewController = [ViewController new]; mockController = [OCMockObject partialMockForObject:viewController]; // Create the mock and change implementation to return our class id serviceMock = [OCMockObject mockForClass:[InterwebzService class]]; [[[mockController stub] andReturn:serviceMock] service]; // Define expectations [[serviceMock expect] downloadTweetsJSONWithSuccessBlock:[OCMArg any]]; // Run the tested method [viewController tweetsButtonTapped:nil]; // Verify - throws exception on failure [mockController verify];
- 26. Testing one layer • Isolate dependencies • Objective-C is highly dynamic - we can change implementations of private methods or static methods • We can avoid IoC containers for testing
- 28. Accessing private methods @interface ViewController() - (void)startDownloadingTweets; @end ... [[mockController expect] startDownloadingTweets];
- 29. Static method testing • Through separation to a method @interface ViewController() - (NSUserDefaults *)userDefaults; @end ... id mockDefaults = [OCMockObject mockForClass:[NSUserDefaults class]]; [[[mockDefaults expect] andReturn:@"Setting"] valueForKey:[OCMArg any]]; [[[mockController stub] andReturn:mockDefaults] userDefaults];
- 30. Static method testing • Through method swizzling void SwizzleClassMethod(Class c, SEL orig, SEL new) { Method origMethod = class_getClassMethod(c, orig); Method newMethod = class_getClassMethod(c, new); c = object_getClass((id)c); if(class_addMethod(c, orig, method_getImplementation(newMethod), method_getTypeEncoding(newMethod))) class_replaceMethod(c, new, method_getImplementation(origMethod), method_getTypeEncoding(origMethod)); else method_exchangeImplementations(origMethod, newMethod); }
- 31. Normal conditions apply despite it’s iOS & Objective--C
- 32. Problems of „mobile devs” • Pushing code with failing tests • Lot’s of hacking together • Weak knowledge of VCS tools - merge nightmares
- 33. Ending thoughts • Think first (twice), then code :) • Tests should come first • Write the failing test, pass the test, refactor • Adequate tools can enhance your testing experience
- 35. Thanks!
- 36. Questions