You said a couple of things that came across as
complete gibberish. Which is my clue that I've
completely misunderstood some major point...
What I still don't know is how to set up the
executables I need...
I've been going through much the same.
What I'm used to:
I have my application, its source files, its
target, it's executable .app and bundle of
resources, etc.
I also have a set of tests, which may include
shell script to run the test(s), application
script that the shell script feeds to the
application to run the test(s), other files
that are fed to the application or are
made available for the application to find
when the test is run and then put back in
their box when the test is completed, and
some way to determine and report whether
tests succeeded or failed. And I have a
test library manager which stores all of
the above in this paragraph, helps me select
which test or tests to run this time.
I invoke my script, telling it which tests
to run (or * or "all"), it asks the test
repository for the pieces it needs for each
test, runs it, the results are checked and
recorded; if the test fails additional info
is added to pin-point and document the failure;
then it moves on to the next test, if any.
When it's done if gives me a pass or fail
on the whole set (if any one failed, the
whole set "fails"), and takes me to the
diagnostic info; it may even display the
diagnostic info, but at least it gives me
a list with additional info, such as "every
test in this sub-category failed". And
it's a semi-batch process.
That's what I'm used to, but I realize that
the current notion of unit testing doesn't
quite mesh with that.
http://developer.apple.com/documentation/DeveloperTools/Conceptual/UnitTesting/Articles/CreatingTests.html
http://chanson.livejournal.com/119097.html
After reading the above, my understanding
(lack of understanding) of current unit testing
approach:
My tests are code, more specifically functions
or methods, written in C or Objective-C or C++
or Objective-C++ or whatever, that invoke
various methods or functions in my classes that
are under test. The functions or methods under
test can be in a frame-work or in an application
but need to have been built (assembled, compiled,
link-edited...) in a way that enables debugging
with gdb or its equivalent for break-points to
work.
There is some similarity in that underneath
there is a script that runs the tests, and
the script invokes otest or whatever.
otest or whatever is what runs one or more of
the tests. I can't just enter names of
test-sub-sets or a list of specific test names
into a list and have it run them; but have to
break open the hood to get at the command line
arguments each time I do a run, specifying an
individual test, or letting it default to all.
While it's running my tests, it treats the
application as something the tests depend on,
not the other way around; i.e. the tests
are not compiled and linked into a library
or frame-work with an application depending
on them from a link-editor POV. From a project
management POV the tests depend on the class
or app that is under test.
I see the tests referred to as a "test bundle"
but am not sure what the important implications
of that are beyond those of any directory of
schtuff to be considered in some sense as one
thing. I see "test bundle" and "target" mentioned
in close proximity, and that seems to be saying
that the tests do get built into their own
library or frame-work of some sort.
I don't see exactly how the "Bundle Loader"
comes into play. "Assign the value$(BUILT_PRODUCTS_DIR)/MyApp.app/
Contents/MacOS/MyApp to the Bundle Loader setting. Select the Unit
Testing collection. Assign the value $(BUILT_PRODUCTS_DIR)/
MyApp.app/Contents/MacOS/MyApp to the Test Host setting. Because
they use the same value, you can also set the value of this setting
to $(BUNDLE_LOADER)." isn't clear at all, though there appears to be
what may be a glimmer of future enlightenment in CH's article...
just not quite all there, yet.
$(BUILT_PRODUCTS_DIR)/MyApplication.app/Contents/MacOS/MyApplication
seems to be saying to set the value of the Xcode
variable BUILT_PRODUCTS_DIR which will set an
environment variable it uses to the path to your
.app and similarly for setting BUNDLE_LOADER to
some path, but I fear clarity is buried in the
notion of which object code library/framework is
being linked to what application. Until then,
I fear the notion of the "test bundle" being
"injected" into the application is out of reach.
Is this just a fancy way of saying that the
link-editor will let the application access the
library or is that completely backwards? All
I get from CH's article is that "inject" means
"inject" and does, indeed, involve some dyld,
but not really what "inject" means.
From CH's first article, I take "test rig" to
be a stub application that the test kits provide
which provide enough functionality to invoke the
methods in your test bundle, for when you're
testing a frame-work. I'm not sure about the
part about "appropriate" test rig, not knowing
the possibilities.
And he tries to explain the above part of the
guide: "If you're testing an application, you
need to specify the application as the Test Host
and Bundle Loader for your test bundle in its
configuration's build settings. The Bundle Loader
setting tells the linker to link your bundle
against the application that's loading it as if
the application were a framework, allowing you
to refer to classes and other symbols within the
application from your bundle without actually
including them in the bundle. The Test Host
setting tells RunUnitTests to launch the specified
application and inject your test bundle into it
in order to run its tests." But the terminology
seems to be getting in the way. "Application
being tested", "framework being tested", "framework
of tests", "framework of tests to apply to the
framework being tested", and something like
"executable of the framework under test",
"executable of the application with which the unit
tests should be linked" (in some cases that will
be the "test rig"), "executable of the application
being tested" and such might be more clear.
Nor is any of the section of the guide on
"Running Your Tests" at all clear, except that
it appears we're supposed to conduct surgery on
something we're not shown and without knowing
anything about its anatomy. Seeing an actual
example test, screen images of the process
of setting up the environment variables,
editing the RunUnitTests script, etc., would
be very helpful.
I don't see what determines whether a test
succeeds or fails or how it gets reported
(though I do see the nice screen shot of it
being displayed prettily), so I'm guessing
that each test function/method has to have
that written directly into it... somehow.
I haven't actually seen an example of exactly
how that is done.
For break-points to work, both the app (or what
if I'm testing a class frame-work?) and the
tests have to have been built so that gdb will
work (i.e. no load symbols lazily, yes debug,
etc.).
What I see is, once again, lots of hand-waving
(leger de main?) but not how the nuts and bolts
fit together properly for it to work, and to
do it properly I neeed to see those nuts and
bolts and other parts all laid out on the table
with the schematics and assembly instructions and,
preferably, the animated video of the pieces
being assembled, and, also preferably, all of
that documentation should be in one place
where I can look at multiple sections at the
same time.
CH's articles provide a little bit of a bridge
between what is probably the unit testing set-
up philosophy, and the cursory material in the
"guide", but I still have a couple disconnects
in what might be appropriate material to lead
up to CH's articles, which would lead up to
the "guide", which really should but does not
cover it all ab initio.
Other stuff run across along the way:
http://homepage.mac.com/ruske/ruske/C2127905073/E676863740/index.html
_______________________________________________
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