This document discusses testing in iOS applications. It explains why testing is important for reliability, preventing regressions, and allowing confidence during refactoring. Some challenges to testing include heavy dependence on UI code and non-testable code. The document recommends separating UI and service interaction code to make it more testable. It introduces the Kiwi and OCMock testing frameworks for iOS and provides examples of writing tests using these frameworks. It also discusses how to test private and static methods as well as isolate dependencies through mocking. The document emphasizes that best practices for testing apply to mobile development as well.

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

12. Separation of concerns

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

27. Accessing private methods

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

34. Ending thoughts
• Practice!

35. Thanks!

36. Questions