Presented by: Ross SharrottLong Weekend KK

Follow me/us: @rsharrott @long_weekend

• IT & Sales Managers•Entrepreneurs•Geeks•Tokyo, Melbourne, New York

• B2C Apps• Contract Development– Specialize in iOS & Android

• Consulting– Training–Mobile Strategy for Enterprise– App Development strategy &

implementation

• Practical > Theoretical

• The world is not perfect.

• We are lazy.

1. Why Unit Test?2. Why don’t iOS Devs Do

It?3. The Tools4. Q&A

1. Why Unit Test?2. Why don’t iOS Devs Do

It?3. The Tools4. Q&A

• It takes longer to write tests.• I’m the only developer (and I’m

amazing)• That’s QA’s job (I’m a developer)• My code takes input from someone

else.• My boss doesn’t give me enough

time to test.

• Tests save time.• Your own code looks like new code

after 6 months.• QA is there to help you find real /

obscure problems, not regressions.• Unit testing is for what you do with

inputs.• Your boss will give you some time to

get started, just ask.

1. Why Unit Test?2. Why don’t iOS Devs Do

It?3. The Tools4. The future?

< SDK 2.2 had no unit testing at all. Then Unit testing in Xcode, frankly, sucked.– Sentest reported the unit tests at build

time.– Application State was inaccessible.– Logic tests only.– Hard to debug tests.– IDE integration was poor – non-existent.

• Functional & Application testing basically did not exist.

• Continuous Integration was nigh impossible.

• We are all spoiled by the tools in most other worlds – selenium, _test, _cover, _mock

• GHUnit–Made testing on the device & with state

possible

• FoneMonkey–Made selenium like testing possible

• Various Others…• The problem:– No IDE integration, somewhat annoying

to run.

1. Why Unit Test?2. Why don’t iOS Devs Do

It?3. The Tools4. Q&A

Unit Testing:– GHUnit– OCUnit–Continuous Integration

UI & Integration:– Automator, FoneMonkey– iCuke, UISpec, etc.

• Pros– Running a subset of tests.– Nice viewer to see the test results.– Setup/Teardown on class or methods– Can run on Continuous Integration– Can read Sentest so you can switch later

• Con– Additional setup, required for every project– New versions of Xcode can break this setup

• Pros– Easy to run with Xcode (CMD + U)– Easy to create new tests (CMD + N)– (Almost) no setup– Can be run on Continuous Integration

• Cons– No class setup/teardown–Must run the entire suite every time

• New test: CMD+N• Objective-C Test Case• You get something like this:- (void)testAppDelegate{ id yourApplicationDelegate = [[UIApplication

sharedApplication] delegate]; STAssertNotNil(yourApplicationDelegate,

@"UIApplication failed to find the AppDelegate");}

Deinflector *bulldog = [[Deinflector alloc] init];

NSArray *results; NSString* msg = @"expected deinflected string did not match!”;

// Check deinflection types results = [bulldog go:@" かけた "]; STAssertEqualStrings([[results objectAtIndex:0] word], @" かけた ", @"1st %@"); STAssertEqualStrings([[results objectAtIndex:1] word], @" かける ", @"2nd %@", msg); STAssertEqualStrings([[results objectAtIndex:2] word], @" かく ", @"3rd %@", msg);

• CMD + U• Xcode will build & run the test suite• You get in console:Test Case '-[CardTagTest

testUpdateLevelCounts]' passed (0.345 seconds).

Test Suite 'CardTagTest' finished at 2011-10-20 05:44:39 +0000.

Executed 3 tests, with 0 failures (0 unexpected) in 1.528 (1.529) seconds

• Good News:– It can be done using xcodebuild & the

simulator–Most of the popular CI’s can work

• Bad News:–Must have xcode installed – so need a mac– OCUnit doesn’t put out junit output by default

• Tools exist for this

– Not a lot of Code Coverage tools available yet

• Automator– Test automator, uses javascript– Included in Instruments

• iCuke– New to the scene, seems like a good

start but we haven’t jumped in yet.Future (testing) proof your projects:

Set accessibility tags in your apps

Follow me/us:@rsharrott @long_weekend