Apple iPhone Tech Talk London 2009: Testing and Debugging Your iPhone Application

Just before this session, I had an interesting discussion with Mike Llewellyn, author of Broadersheet, about unit testing. He uses defensive code with asserts and logging and doesn't think there is enough value in unit testing for mostly UI code.

However, Apple have converted to using unit tests and are making it easy for XCode developers to take advantage of them.

At Kizoom, we’ve used unit tests to test our controller code — ensuring that given a particular input, it goes to the right result view with the appropriate model. This is made easier by using three20 — the result view is identified by a string rather than an object (though using OCMock would let you assert about objects too).

Here’s what Michael Jurewitz jurewitz@apple.com — App Frameworks & Dev Tools Evangelist had to say:

• thousands of tests in Core Data
  • roughly 90% coverage (that’s very impressive — it’s hard to maintain more than 80%)
  • fully test driven from the start
• similarly large amount of tests in WebKit
• Application tests get injected into application and can drive running app

static analysis

• has found and fixed thousands of bugs in Snow Leopard & iPhone OS :-)
• use it to learn and enforce good Cocoa practices
• detects dead stores: unused variables
• see “Run Static Analyzer” in Project properties / Build
  • might not want to have this for all configurations
  • gets picked up by xcodebuild on the command line

organizer

• check the console if you get a crash
• can download app’s data from actual device:
  • check Applications under Summary — your app will have a disclosure arrow

beta testing

• create a distribution certificate in the iPhone portal
• create an adhoc provisioning profile
  • can still use a wildcard identifier
• load it up into XCode
• make a beta testing config
  • duplicate the release config
  • set Code Signing Entitlements to Entitlements.plist (a new file)
  • use appropriate provisioning profile
  • create new Entitlements: set get-task-allow to false
  • disallows debugging
  • if you want people to debug, then send them a debug build…
• build + send zip of build + provisioning profile to beta testers
• they can unzip & drag both to iTunes

crashes

• can get crash log from user — iTunes syncs them
  • Mac & Windows store them in different places, but can find…
  • also available in iTunes Connect
• can get Organizer to symbolicate crash log for you
  • your .app and .dSym must be locatable by Spotlight — so keep them

low memory logs

• see count of pages: each page is 4Kb
• SpringBoard shares memory with your app — it handles presentation on screen
• mediaserverd is iPod
• if you find that something other than your app or SpringBoard is the largest memory user, then file a bug…

other crashes

EXC_CRASH (SIGABRT)

• 0xdeadfa11 — termination due to too much memory
• 0x8badf00d — watchdog timeout

EXC_BAD_ACCESS (SIGBUS)

• objc_msgSend — happens when you message a deallocated object

instruments

• Zombies template — record reference counts & enabled NSZombie detection
  • see extended detail view using rectangle icon at bottom of window
  • shows stack trace for each event
  • can jump through to code view, then jump into XCode editor