How to organize unit testing of a library project in Xcode?

Question

I'm not yet a fan of integrated development environments, but I'm trying to overcome my prejudices and learn Xcode. (Eclipse/CDT is next; I couldn't get that to work for me either when I tried last year, but that's a separate issue.)

I am writing some new code in a new project that will become (part of) a small library. I want to unit test it, too. How do I explain to Xcode that I'm building a (shared) library, but I also want to use it in a test program, compiled from separate source that won't be in the shared library?

Source code:

• atom.c
• atom.h
• test-atom.c

Produced files:

• libatom.dylib
• test-atom

I've got atom.c and atom.h compiled into the library. I'm just not sure how to organize things so that I can also build test-atom to link with the library. I'm assuming that when I've got that sorted, adding the library for the test support code that test-atom.c would be relatively straight-forward - even though it isn't under Xcode control yet.

FWIW, I primarily work in C rather than Objective C.

Answer 1

You need two targets in your project; a target in Xcode produces a product which is a library, executable, or some other output.

Thus you'd have a target to produce libatom.dylib, which I suspect you've already set up, and another command-line executable target to produce the test-atom executable for you to run to test your library.

Once you've added the test-atom target, you should Get Info on test-atom.c and remove its membership from the libatom.dylib target, and add it as a member of your new test-atom target. The target membership of a file is what determines whether building a target will try to compile/copy/link that file. (What the target does with the file depends on what build phase it gets added to when it's made a member.)

You should also Get Info on the libatom.dylib entry in your Products group, and make that a member of the test-atom target as well. That will cause the test-atom executable to link against libatom.dylib.

Finally, Get Info on the test-atom target (not the product) and in the General tab, add a dependency on the libatom.dylib target. This will ensure that building the test-atom target will always first build the libatom.dylib target.

Answer 2

Edit: See Automated Unit Testing with Xcode 3 and Objective-C (a more recent version of the article I originally linked to, as pointed to in a comment below). Also see What is the best way to unit test Objective-C code? While you clearly aren't using Obj-C yet, the basics of setting up new targets will be the same for C code, and the OCUnit specific stuff is very representative of how unit testing works in an IDE.