Re: otest -- only useful for bundles?
Re: otest -- only useful for bundles?
- Subject: Re: otest -- only useful for bundles?
- From: Chris Hanson <email@hidden>
- Date: Mon, 21 Nov 2005 18:54:24 -0800
On Nov 6, 2005, at 4:49 PM, James Bucanek wrote:
- When testing a framework or dynamic library, only the code for
the tests are compiled into the unit test bundle. The otest is
executed to load both the unit test bundle and the framework to be
tested and execute the tests.
This is just slightly incorrect. When otest is used to run the tests
in a dependent unit test bundle, it loads just the unit test bundle
exactly as it does with an independent unit test bundle. Because the
dependent unit test bundle links against the framework or dynamic
library it contains tests for, it is loaded as a prerequisite for the
unit test bundle automatically. There's no involvement by otest in
this; it's all handled by the dynamic loading machinery. (All of
this applies to CPlusTestRig as well.)
- When testing an application, the code for the tests are compiled
into the unit test bundle. When it come times to execute the tests,
special DYLD_... environment variables are set so that the dynamic
linker links the target executable to special unit test frameworks
and the unit test bundle (which contains the actual tests). When
the application begins executing, the "injected" bundle/framework
intercepts the application's execution, runs the tests, and exits.
Again, just slightly incorrect. Special DYLD_ environment variables
are used to cause an additional framework to be loaded into the
application when executed. When that framework is loaded, it looks
for the specified test bundle. The test bundle (or the test
framework it links against) intercepts the application's execution,
runs the tests, and exits.
-- Question #1 --
I also feel that this is something that really should be part of
the RunUnitTests script. It would take only minor modifications to
RunUnitTests for it to look for a build setting like TEST_SET and
adjust its launch arguments accordingly, rather than force the
developer to reverse-engineer the script and duplicate all of the
required set-up and initialization that the unit test framework
requires. Especially since those requirements don't seem to be
documented anywhere.
Please file an enhancement request.
-- Question #3 --
Does the code I inserted into main() to run the test automatically
turn off when the application is executed normally? Will it not
spit out those annoying messages? How does my app know that tests
should be run vs. when it should execute normally? Both the example
code and the code I have above *alway* run the tests and exit. As
its written now, my application won't ever run.
As you've surmised, the code you inserted into main() does not
automatically turn off. You need to explicitly enable and disable it
if you build it into your application or tool. This is why it's
preferable to inject a test bundle and to have some mechanism within
your application or tool that the test bundle can hook into when it's
loaded to cause the tests to be run.
-- Question #4 --
When configuring a dependent unit test to test a framework or
dynamic library, how should the target be configured? How does
otest know which frameworks and libraries are being tested?
As I described above, neither otest nor CPlusTestRig has this
knowledge, nor do they have any need for it. It's handled
automatically by the dynamic loader, since a dependent test bundle is
linked against the target framework or library.
-- Question #5 --
Can you configure a dependent unit test to test a static library?
Yes and no. Yes, in the sense that there should be no impediment to
creating a dependent unit test bundle that links against a static
library and tests the code within that library. No, in the sense
that when you do so it's not "really" a dependent unit test bundle
since the static library will actually be incorporated into the unit
test bundle -- it's a static library, after all.
One thing you'll probably want to do though is, if you're building a
static library containing Objective-C code, when you link against it
you'll probably want to pass either -ObjC or -all_load in the
OTHER_LINKER_FLAGS of the targets that link against it. See the ld
(1) man page for details.
-- Chris
_______________________________________________
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