Re: CPlusTest in Xcode 2.3
Re: CPlusTest in Xcode 2.3
- Subject: Re: CPlusTest in Xcode 2.3
- From: John Richetta <email@hidden>
- Date: Fri, 14 Jul 2006 14:29:55 -0700
At 12:50 PM -0700 7/14/06, Aaron Montgomery wrote:
On Jul 14, 2006, at 11:59 AM, John Richetta wrote:
1. Has this problem Aaron asked about been resolved or
investigated? I have the exact same problem(Xc 2.3, OS X 10.4.7):
simple TestCases, without any setup and teardown (yet), and which
consistently crash at program exit, whenever there is more than one
test case.
Not by Apple. It has problem id 4560190 and is still listed as open.
However, adding the "Other C Flag" of -fno-use-cxa-atexit in the
Unit Tests target will prevent crashing. The problem appears to be
how termination routines are being executed when libraries are
unloaded. CPlusTest is not the only situation where this is
problematic so I'm guessing it will be fixed, I just don't know when.
Thanks for the quick help - much appreciated! My test code is now
running seemingly smoothly.
I figured it was something about termination routines, but exactly
what isn't clear (note that my target has been converted to be an
application, rather than a loadable bundle). It could still have
been an error on my part showing up at termination time. Since
having more than one test case seems to be the trigger, maybe
something is being disposed twice (but I think I can rule that out in
my code). Based on a reading of the man page, it appears that exit
code is still called with this option (good), just not in a
standard-compliant fashion.
a. why it says the test target doesn't need the source code
under test to be added to it (the grey box at the top of page 12
baffles me); how does the "injected" bundle "[access] any source
code required for the tests"??
Your application should be exporting its symbols.
The documentation doesn't appear to state this important fact
explicitly. I guess most people are just using things as directed,
and thus staying out of trouble. ;)
So the injected bundle uses your application the same way your
application uses prebuilt libraries. It knows that it needs to call
function foo() and knows where foo() is located inside your
application's compiled code.
This was the key point I missed, primarily because, in the interest
of keeping things simple(?), I'd opted to create an independent test
target initially (even though I prefer dependent), and in doing so,
had glossed over the "dependent" portion of the document. I guess
sentences two and three in the second-to-last paragraph on page 11
explain this clearly enough, if tersely. Laboring under old school
assumptions, I'd just never thought that symbolic information for an
application would suffice to link to its symbols (still a trifle
fuzzy to me how that works).
b. why I'd want to "inject" a bundle into an application (and
specifically, exactly what that means) to test it - I normally do
all unit testing in stand-alone applications. There are cases
where testing within a complete application is desirable, but they
are much less common for me. I'm not sure why I'd want any
significant machinery to achieve this - why not simply
conditionally compile my tests into a (non-final) target?
Completely naive response here. I'm guessing that injecting the
bundle just means that you are adding some code to be executed in
the context of the running application. In some sense, your
application's code is being injected into Mac OS X's system code
every time it is run.
I guess the term "injected" seemed colorful enough that I expected
something less ordinary.
I guess you could achieve the same result with conditional
compilation. I like the fact that my testing code is separate from
my production code (not intermingled). Also by not mingling the
code, when I run gcov (or lcov) while doing unit testing, I just get
coverage results from the application code and not both from the
application code and the unit testing code. In larger systems, it
will allow application programmers and quality controllers to each
have their own codebases that don't overlap (although they certainly
need to be in agreement about what the application functions are
supposed to be doing).
So far, I've kept my test code pretty separate, although admittedly,
I don't defer connecting the two until runtime. But isn't the intent
of dependent testing that it be executed at build time? (Desirable,
IMO.) Since I haven't yet used these coverage tools, I don't follow
why they will omit the test case code, in your setup, but I'm not
entirely sure that's desirable anyway (since test cases may also
include nontrivial code, and presumably do not occupy a large portion
of output statistics).
I guess one definite advantage of the "injected bundle" method is
reduced compile time. Another is less test target maintenance
(adding source files to two targets, rather than one).
Well, thanks for your input. I'm not meaning to be argumentative
here; just trying to understand clearly.
I've done a fair amount of digging and cannot find it.
OK, thanks.
Hope that helps, I put together a short MacTech article on this
(hopefully it will be published), but I can't say that it will help
you with answers to Question 2. It is more focused on how to set up
the project targets rather than why you would want to do unit
testing in this particular fashion.
Great - looking forward to it. Thanks again for your timely, very
helpful reply.
-jar
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden