Part of the online course that I took from Stanford on iPhone app development involved choosing a final project. My top-level criteria for choosing a project included:
- Incorporate several different iOS technologies.
- Make use of an external web service and API.
- Interaction with an external web site.
What I eventually settled on was a concept for allowing a user to view and edit their iPhone Address Book contacts both within an app as well as in a full web browser.
This functionality is already available as a service now at iCloud.com. My plan was to start with this capability and over time begin to add new functionality (social sharing, etc).
The Contacts2Web app is now available in the App Store. In this document, I will cover some of the details that went into developing the app.
Posted in iOS
Tagged address book, code coverage, core data, core foundation, debugging, google analytics, instruments, iOS, leak, memory allocations, parse, singleton
I recently posted an article called Setting up and using Code Coverage. As I mentioned there, code coverage is useful for seeing what portions of your code have been exercised. What code coverage can’t do though is to ensure functional correctness – this is where functional coverage comes into play. Functional coverage allows you to determine when you have exposed your code to a sufficient enough set of stimulus, including hitting corner cases, that you have a high confidence in its functionality.
My background includes experience as a hardware verification engineer, where the teams I was part of used both code coverage and functional coverage as essential tools in test development. In the Wikipedia section on SystemVerilog (a hardware description and verification language) there is a nice write-up on Coverage where the difference between code coverage and functional coverage is discussed.
What is a Coverpoint?
I wanted to employ some functional coverage as a guide to my unit test development. In the SystemVerilog language mentioned above, they have the concept of coverpoints and covergroups (group of coverpoints). I found a nice document called SystemVerilog Testbench Automation Tutorial where there is some good information about these concepts starting in the section titled “Functional Coverage”.
A coverpoint is essentially a measurement point where an event (such as values taken on by a variable) can be recorded, along with bins for how many times specific values (or range of values) occurred for that event.
In my last post I talked about how to setup for Code Coverage and made a reference to unit testing. In this article I wanted to share my experience with setting up to run unit testing.
A great place to start is the Apple document Xcode Unit Testing Guide.
Setup target and initial test suite
Choose File > New > Target …
In the iOS section, select Other, then select the Cocoa Touch Unit Testing Bundle template.
Since my app is called ContactsOnline, I’ll name my product (new target) ContactsOnlineBasicUnitTests.
This creates a test suite by the same name ContactsOnlineBasicUnitTests.m, within a group called ContactsOnlineBasicUnitTests.
Unit-test targets define one or more test suites.
My background includes many years of Verification work on complex computer and graphics chips, so I was happy to learn that Xcode had some support for testing and code coverage. Code coverage is very useful as a guide to developing tests to let you see what portions of your code have been exercised.
The following example code coverage results are displayed using the tool CoverStory. They show what percentage of various classes have been exercised in the left pane, along with details about which lines in a particular file have not been covered in the right pane (highlighted in red).