Re: CPlusTest in Xcode 2.3
Re: CPlusTest in Xcode 2.3
- Subject: Re: CPlusTest in Xcode 2.3
- From: Aaron Montgomery <email@hidden>
- Date: Fri, 14 Jul 2006 23:36:16 -0700
On Jul 14, 2006, at 2:29 PM, John Richetta wrote:
At 12:50 PM -0700 7/14/06, Aaron Montgomery wrote:
On Jul 14, 2006, at 11:59 AM, John Richetta wrote:
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.)
When you build the "Unit Tests target" it will run the test code
inside your application, but you still have to build the Unit Tests
target to run the code whether it is a dependent test or not. By
making the unit tests target dependent on the application target, you
are insuring that you are not testing an obsolete build of the
application. If it isn't dependent on the App target, then when you
build the Unit Tests target, it will just use whatever executable is
in the build directory (even if you have changed the source code
since your last build).
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 set the compiler/linker options to set up profiling for the
application target and not for the unit test target. The result is
that profiling data is generated when the application target's code
is being executed (since it was built with profiling turned on) and
not being generated when the unit testing target's code is being
executed (since it was built with profiling turned off). If all your
unit testing code was part of your application target, you either get
to turn profile generation for everything or for nothing.
Well, thanks for your input. I'm not meaning to be argumentative
here; just trying to understand clearly.
No problem, I'm still trying to figure it all out myself.
Aaron
_______________________________________________
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