I have a few things to add to the woefully incomplete official documentation on setting up automated tests in your iPhone apps:
- You need to add your main application executable target as a direct dependency of the test target, so that you’re always testing against your latest build. Do this by double-clicking on the test target, going to the “General” pane in the properties dialog, and adding your app under “Direct Dependencies”. (This was actually mentioned in the OCUnit tutorial for Cocoa, but not the one about iPhone testing.)
- Your linker needs to know about the objects you’re testing. An easy way to do this is to add the .m files for those classes to the “Compile Sources” group in your test target. You’ll also have to make sure you link against any frameworks used by these objects. (You could also tell your app target to export all symbols, then link your test target to it as you would a library.) (Thanks to Chris Hanson for pointing out this procedural improvement in comments.)
You need to explicitly link the object files of the classes you’re testing. These are the “.o” files in your build folder. To do this: Double-click on the test target, go to the “General” pane, add a new item under “Linked Libraries”. In the dialog that pops up, choose “Add Other…” and add your class’s .o file. - When you run your tests, one failure looks like two: Failed tests show up in Xcode as errors (just like compile errors, &c). Any test failure triggers a second error, and you’ll see something like “Failed tests for architecture ‘i386′ (GC OFF)”. The docs never say so, but this appears to be normal. Fix the failing test, and it goes away.
Anything else to add? Drop us a comment!
You don’t “need to explicitly link the object files of the classes you’re testing.” It’s unclear how you got the idea that you do.
Either you need to add the sources for the classes you’re testing to your test bundle – making it what the unit testing docs call an “independent” test bundle – or you need to have your test bundle link against your application or library, making it a dependent test bundle.
Linking your test bundle against the object files directly shouldn’t ever be necessary.
Oh, one other thing: If you’re trying to link your test bundle against an application (via the Bundle Loader build setting), you’ll also have to tell your application target to export all of the application’s symbols.
Applications don’t default to exporting all of their symbols, unlike frameworks and static libraries.
Chris – Thanks for the feedback.
I came to linking the object files directly because I got a linker error, and that was the thing I found that fixed it. I am, of course, always open to better ways of doing things.
At your suggestion, I’ve added the .m files for the classes under test to my unit tests target. It works well, and I don’t have to go hunting for the .o files. Thanks for the guidance. I’ll update the post accordingly.
Pingback: Kickass Labs » Blog Archive » Quick Hits: Unit Testing iPhone Apps | Mac Affinity
You ever run into a situation where your general test fails, but the individual tests are all OK? I tried to add OCMock to my application, and I keep getting a general error:
error: Failed tests for architecture ‘i386′ (GC OFF)
Marc – No, that’s a new one on me, but then I’m pretty new at this. I have noticed that things like linker failures can also trigger that error message – do you have any feedback from the build besides that one message?
A couple things that have tripped me up:
1. In order to do app testing, you MUST build and run on the device; in order to do logic testing, you must build and run on the stimulator.
http://stackoverflow.com/questions/1092396/iphone-unit-testing-xcode
2. You can only test on devices running 3.0.
Pingback: Unit Testing on the iPad « Bloq Software