• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Testing C functions using OCUnit
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Testing C functions using OCUnit


  • Subject: Re: Testing C functions using OCUnit
  • From: Greg Parker <email@hidden>
  • Date: Sun, 15 Feb 2009 10:50:30 -0800


On Feb 15, 2009, at 10:32 AM, Martin Redington wrote:

In my projects, I tend to define methods which need access to member
variables as class methods, and related functions, which do not need
"direct" access to any internal object data, as C functions, like the
simple example below.

@implementation FunctionTestAppController

+ (id) sharedController
{
	return [NSApp delegate];
}

- (BOOL) someMethod
{
       // would normally access some ivar.
	return YES;
}

@end


BOOL SomeFunction() { return YES; }



I've recently been implementing unit testing, following
http://developer.apple.com/mac/articles/tools/unittestingwithxcode3.html
- i.e. the main app binary is specified as the bundle loader, and
testing is done via injection of the unit test bundle, with a clear
separation between application and test code.

Everything works fine for objective-C methods, but I get linker errors
when I try and reference any of the C functions defined in my
application code. nm reveals that the symbols are present in the app
binary, but the linker doesn't seem to be able to see them.

Is there a recommended, or even a good way, to get the test code to
link correctly to the applications C functions?

What does `nm -m` say? It's likely that your C function's symbol is present but marked non-external, which means it's available for debuggers but not for linking. (`nm` alone provides a single-letter description of the symbol, and `nm -m` prints the description in human- readable form.)


If that's the case, you can change your executable's symbol management in Xcode. I think the options are to provided an exported-symbol list that names the C functions explicitly, or change the stripping level to none so they're all available. You should do this only for testing purposes and not for your final release configuration; keeping symbols hidde makes your app launch a little faster.

(The Objective-C code probably works because the C linker is mostly not used for 32-bit Objective-C linking. But it's likely that a 64-bit version of your app would run into the same problem for Objective-C code.)


-- Greg Parker email@hidden Runtime Wrangler


_______________________________________________

Cocoa-dev mailing list (email@hidden)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: Testing C functions using OCUnit
      • From: Martin Redington <email@hidden>
References: 
 >Testing C functions using OCUnit (From: Martin Redington <email@hidden>)

  • Prev by Date: Testing C functions using OCUnit
  • Next by Date: Re: Testing C functions using OCUnit
  • Previous by thread: Testing C functions using OCUnit
  • Next by thread: Re: Testing C functions using OCUnit
  • Index(es):
    • Date
    • Thread