Infinite Loop

Unit Testing Load of Image Resources

I recently decided to try out the Test Driven Development approach for a new utility iPhone App which I’m currently working on. My goal was (and still is) to perform TDD in every possible corner of the design and implementation of the App. As it happened the project was kicked off about the same time as “Test-Driven iOS Development” by Graham Lee was released. This book shows how to develop an iOS App from scratch using TDD throughout the entire process – including design and test of the UI aspects. Graham’s book is one of the first (if not the first) I have seen which also covers the UI parts – most other sources I have seen tend to just write this off as not practically possible. The techniques described below are heavily inspired by some of the examples and methods described in the book. Anyway, if you haven’t purchased it yet, I can highly recommend you do so – it’s a great book.

One of the tasks of my new iPhone App is to display a small icon for indication of battery status for a connected UPS (Uninterruptible Power Supply). The icon will just be loaded from the bundle resources depending on the status of the power supply. It’s fairly straightforward to write a bunch of tests to verify that the correct image is selected for the various states, e.g.:

- (void)testImageNameForUpsNotPresent {
  UPSStatus *status = [[UPSStatus alloc] initWithStatus:notPresentTestData];
  assertThat([status imageName], equalTo(@"UPS_NotPresent"));
- (void)testCanLoadImageForUpsNotPresent {
  UPSStatus *status = [[UPSStatus alloc] initWithStatus:notPresentTestData];
  assertThat([status image], notNilValue());


Comments (2) | Trackback

Code Coverage and fopen$UNIX2003 Problems

A couple of readers have reported they were unable to get code coverage on LLVM working properly after following my description in Code Coverage with Xcode 4.2. The problem would manifest itself in a somewhat cryptic error during execution of the unit tests:

Detected an attempt to call a symbol in system libraries that is not present on the iPhone:
fopen$UNIX2003 called from function llvm_gcda_start_file

The discussions have been lively with various suggestions on tweaking compiler flags, inclusion of libraries, missing files in target, etc. It wasn’t until I ran into the problem myself – even after following my own advice step by step – that I decided to dig deeper into the cause of the problem. Fortunately it turned out that the solution had already been described in the discussions and it’s a rather simple one too.

Comments (2) | Trackback

Code Coverage with Xcode 4.2

This tutorial is just a small follow-up on one of my earlier posts about how to set up code coverage in Xcode.

With the release of Xcode 4.2 code coverage is finally supported using Clang / LLVM. Opposed to what I described in the earlier post you no longer need to force the use of GCC to get code coverage metrics in your unit tests. Since Apple has also decided to drop support for GCC you are more or less forced to switch to Clang / LLVM anyway.

In Xcode 4.2 it’s fairly simple to set up code coverage. If you have defined a custom build setting or build rule that enforces GCC 4.2 you will need to remove those first.

Next you’ll need to enable the two build settings “Generate Test Coverage Files” and “Instrument Program Flow” as shown below:


Comments (26) | Trackback

Providing Custom Documentation in Xcode

Whenever you are writing code that is intended for reuse it is important that the API is well documented. This will make it a lot easier for other developers to understand and integrate your code. On top of this it will also make it a lot easier to reuse that code when you need to use it yourself 6 or 12 months down the road.

In this tutorial I will use ILGeoNames as an example for how you can easily generate documentation for your own projects.

I will use the appledoc tool provided by Gentle Bytes. The appledoc tool provides a lot of nice features including the ability to generate Apple-like html documentation as well as the ability to generate and install fully indexed and browsable Xcode documentation sets.

Comments (5) | Trackback

Covering it all up

In the previous two posts I described how you can create unit tests for threaded code as well as how you can de-couple your tests from external errors on the internet.

In this post I’ll show how to use GCOV and CoverStory to ensure that you are actually testing all parts of your code. Or at least obtain knowledge about which parts of your code that are being tested and which parts that are not being tested by your unit tests.

Having a high degree of code coverage in your unit tests helps to ensure that your code will continue working as expected even after you change parts of it, e.g. when fixing bugs, re-factoring it, adding new features, etc.

The coverage data can also be used to show when you have added enough tests to your code. Once you have obtained full test coverage of a certain function, adding more tests for that same function will probably not help you find more bugs in the code. Instead you can now focus your efforts on adding new functionality without having to worry about it breaking behind your back.


Comments (13) | Trackback