Is iPhone Unit Testing Possible?

Lessons Learned: Unit Testing iPhone Apps

This is the first part of a four part series on How to do iPhone Unit Testing. You could also call it Lessons Learned from Unit Testing iPhone Apps. I’ve learned a lot of lessons over the past year doing iPhone Consulting and I want to share them with everyone.

Here is the schedule for this series:

  1. Is iPhone Unit Testing Possible?
  2. How to Create an iPhone Project in Xcode That Can Run Unit Tests
  3. Getting Started Writing iPhone Unit Tests
  4. Pitfalls That You May Encounter when Running iPhone Unit Tests and How to Overcome Them

This is targeted at iPhone Developers, especially those who have done unit testing in other languages and frameworks.

A bit of backstory: My name is Luis de la Rosa and I am an iPhone Consultant. I have been making iPhone applications for clients the past year through my company Happy Apps LLC. I have also been developing Mac OS X apps and Rails apps for the past 3 1/2 years and in other languages for 14+ years now.

To start off, you might ask: Is iPhone Unit Testing even possible? I don’t see it as an option when creating a New Target in Xcode like I can with Mac OS X applications.

Apple says it is not possible. In the “Xcode Unit Testing Guide”, it says

“iPhone OS Unit Testing Support: Unit tests are not supported for iPhone applications.” 

But what this really means is that Unit Test Bundles, which are dynamic, are not allowed on iPhone because dynamic bundles of all kinds are not allowed on iPhone. So the normal way of adding Unit Tests to an Xcode project is not available to you. (iPhone projects are Xcode projects.)

However, there is a way to add unit tests to an iPhone project!

To understand why, you need to understand the two types of targets available to an iPhone project. These two are:

  1. Application
  2. Static Library

To put it another way: the normal Unit Test Bundle target for Mac OS X applications is not available because there are no Dynamic Bundle targets. A Static Library target cannot be executed and we need some sort of execution in order to run the tests. So we need to somehow use an Application target to run our unit tests.

The Application target will need to do the following things:

  1. Find all the unit tests in your Project
  2. Run all the unit tests
  3. Report the results of running the unit tests. This should include the number of successes and failures overall and also the results of each individual test.

You could do this from scratch, but fortunately there are already some diligent and ingenious engineers out there who have already done the work for you.

In tomorrow’s segment: How to create an iPhone Project in Xcode that can run unit tests.

If you found this helpful and/or interesting (hopefully both), please leave a comment.

NSCoderNightDC is going to be studying iPhone SDK Development

NSCoderNight DC is going to be switching gears tonight and starting to study the new Beta Book from the Pragmatic Programmers titled iPhone SDK Development. Why the switch? Because the NDA has been lifted.

It is the first book of its kind that I know of. I ran into one of the authors, Marcel – who I also knew and respected from the Rails world, at C4[2] and he told me about the book.

So if you are in the Washington DC area and interested in learning about iPhone development, we’ll be having weekly meetings starting at 7pm every Tuesday at:
La Madeleine – Bethesda, MD
7607 Old Georgetown Rd
Bethesda, MD 20814
(301) 215-9139‎

More detailed driving / parking directions to La Madeleine – Bethesda, MD

See you there!

10 Things I Learned from C4[2]

I went to C4[2] last month. For the uninitiated, C4[2] is the third (yes we count from zero) conference of its kind, a conference for independent-minded Mac and now iPhone developers, held annually in Chicago, Illinois. It is run by Jonathan “Wolf” Rentzsch, who is an independent Mac / WebObjects consultant.

It was a great gathering and I look forward to going to C4[3] if I have the opportunity. So I thought I’d share my top 10 things that I learned at the conference:

1. Getting like-minded developers together at one place generates a lot of energy, enthusiasm and knowledge sharing.

I think it’d be great if we could replicate what has been happening in the Ruby community and start to have Regional Objective-C conferences. This has started to happen with the iPhone Dev Camps already, but it’d be great to have combined Mac / iPhone Regional conferences, so devs that can’t afford to travel to Chicago and San Francisco can still get involved and interact with each other in Washington D.C., New York, Seattle, Denver, and wherever else we all are.

2. iPhone development has really come into its own, but its knowledge continues to be restrained by the NDA.

We started off with a presentation by Craig Hockenberry of how iPhone has changed the way humans interact with computers in much the same way the mouse did. We ended with a programming contest called Iron Coder (a play off of Iron Chef) which traditionally has been with Mac OS X APIs but this time was on iPhone with an iPhone API. I finally participated (after helping with past Iron Coders by providing licenses of WebnoteHappy as prizes), collaborating with Joe Pezzillo to produce CoreParanoia and also contributed a tiny bit to Jose Vazquez‘s 2nd place Tipster.

The rest of the presentations were not iPhone focused, but there were mentions of it throughout. And it seemed like having an iPhone was part of the requirements for attendance. I personally got a live demo from Tim Burks of his iPhone app Masyu which is a pretty fun puzzle game.

The problem however was that the NDA on iPhone development stifled a lot of the conversation. This generated a lot of complaints and even a t-shirt that rebelled against it.

3. Security is scary, but not as scary as not succeeding.

There was a wild presentation on security that said: don’t pretend to be a security expert. Stick to using the Keychain or bcrypt for passwords, use openssl or gpg. Don’t use installers or open up listeners on ports. Don’t write directly into the DOM. But all of that doesn’t matter if your business doesn’t succeed if you don’t have a nice looking application and it is unstable or slow. Also, filter user-supplied content and write a fuzzer for the content you accept. Make sure you have a security contact, use a crash reporter, and use auto-update securely. Finally, turn off Java in your web browser to prevent against some of the newer, crazier attacks like GIFAR.

4. Mac users really care about user experience (as if you already didn’t know that.)

To reiterate what we all sort of know but sometimes overlook since we are so deep in our code, Mike Lee presented “Pimp My App.” The basics: Use real artists, don’t skimp on your art budget, watch real users use your app, solve a specific problem, and cut as many features as you can.

He also offered some iPhone specific UI tips: start as fast you can, the start-up screen should not be used as a splash screen but more like the real app, restore the state of your app instead of just restarting, don’t block the UI, and think about the user’s first experience carefully.

5. Contractors / consultants are Indies too.

I’ve made applications and I’ve done consulting. Both qualify you to be an Indie, meaning independent from another company. There was a presentation by Andy Finnell on this and it mostly reiterated what I knew but it was nice to hear it from someone else. Basically: make sure you have good contracts, these will help you get paid properly and avoid constraints your future development. I’d add to this that if you can be choosy, it is good to figure out what kind of clients you want to work for and what kind of projects you want to work on and then only choose those to work on, even if it means taking some time off between projects.

6. Pricing sends a message

Rich Siegel of Bare Bones gave a presentation on lessons learned over his career. One of the key ones is that pricing: is a marketing message and shows how you feel about your product. It also needs to consider how much your overall costs are. It also positions you among competitors. That being said, your product / service definitely needs to be differentiated to justify a premium.

7. Warnings should be fixed

This is probably also a no-brainer but I’ve been at a few companies / projects where warnings are tolerated. Mentioned by both Rich and Mike, warnings can be the cause of run-time errors down the road. Its best to generate the most warnings possible and fix them as they come up. You may find it also advantageous to treat warnings as errors, but either way way, fix them.

8. Mac programmers really care about fonts

Minor but revealing tidbit: the fonts at C4 are carefully chosen. Compared to other conferences I have been to, I think this shows that Mac programmers care about design more than other programmers.

9. Twitter is the preferred method of communication in the Mac / iPhone developer community

When I wanted to see what was going on and what people were thinking, I checked Twitter. At other conferences, sometimes we would have IRC back-channels. Using twitter makes the back-channels more open. Also, we voted for Iron Coder via Twitter.

10. Do the simplest thing possible

Mentioned by Craig, Buzz Andersen, and Mike, doing the simplest thing possible, getting feedback and then iterating on that is a good technique when developing products. I knew this before, but many of us are perfectionists and so we have to keep reminding ourselves of this in order to combat the tendency to either add more features or to keep trying to perfect a certain specific part of our app.