NSLog doesn't work with OCUnit
-
Hi,
NSLog doesn't output anything to the console when I run my Test target.
But NSLog outputs lots of text when I run my Application target.
I made the 'Test' target by following this tutorial:
http://developer.apple.com/tools/unittest.html
Any ideas on how to enable NSLog?
Alternatively I can log to a file.. however I am very just curious to
why NSLog for some reason doesn't work when testing with OCUnit.
--
Simon Strandgaard -
On 6/19/05, Simon Strandgaard <neoneye...> wrote:
[snip]
> Alternatively I can log to a file.. however I am very just curious to
> why NSLog for some reason doesn't work when testing with OCUnit.
I have made my own logger instead of using NSLog.
I used the following link as inspiration.
http://borkware.com/rants/agentm/mlog/
Thanks.
--
Simon Strandgaard -
On 6/20/05, Simon Strandgaard <neoneye...> wrote:
> On 6/19/05, Simon Strandgaard <neoneye...> wrote:
> [snip]
>> Alternatively I can log to a file.. however I am very just curious to
>> why NSLog for some reason doesn't work when testing with OCUnit.
>
> I have made my own logger instead of using NSLog.
> I used the following link as inspiration.
> http://borkware.com/rants/agentm/mlog/
Ah, I am too stupid, NSLog has been working all the time.
Xcode has in its 'Build Results' window, 4 icons in the left-bottom corner.
Toggling the 3rd show/hides the captured output.
--
Simon Strandgaard -
FYI: to debug issues like this, add a symbolic breakpoint on NSLog
and start your application in Xcode; it will break when NSLog is
called and you can figure out what code is calling it.
-corbin
On Jun 20, 2005, at 7:07 AM, Simon Strandgaard wrote:
> Ah, I am too stupid, NSLog has been working all the time.
-
On 6/20/05, Corbin Dunn <corbind...> wrote:
> FYI: to debug issues like this, add a symbolic breakpoint on NSLog
> and start your application in Xcode; it will break when NSLog is
> called and you can figure out what code is calling it.
Wouldn't have helped in this occasion because when the unit test
runner ran during the custom build phase it wouldn't have been running
under the debugger anyway.
I think I used run a few to many times in that sentence, but I hope it
still makes sense :)
-- Finlay -
> Wouldn't have helped in this occasion because when the unit test
> runner ran during the custom build phase it wouldn't have been running
> under the debugger anyway.
>
You can run around that issue (pun intended) by running your app in
the debugger with the parameters "-SenTest Self".
--corbin -
On Jun 20, 2005, at 3:51PM, Corbin Dunn wrote:
>> Wouldn't have helped in this occasion because when the unit test
>> runner ran during the custom build phase it wouldn't have been
>> running
>> under the debugger anyway.
>>
>>
>
> You can run around that issue (pun intended) by running your app in
> the debugger with the parameters "-SenTest Self".
But then the new Xcode 2.1 test bundle won't be loaded into your app
so no tests will run. Is there a recommended way of debugging with
Xcode 2.1's test bundles?
The new bundles are nice because you don't have to link your app
against the testing framework and none of the test code ends up in
your deployed app.
-Frank
------------------------------------
Frank M. Midgley
<knarf...>
http://homepage.mac.com/knarf/ -
You simply use "otest" as the host to run your application.
Steps:
1. Add a new executable to your project -- select otest in /Developer/
Tools/otest
2. Double click on the executable, and add two run params:
a. -SenTest Self
b. $(BUILT_PRODUCTS_DIR)/YourBundleName.octest
This makes it REALLY easy to debug OCUnit tests. You can debug an
individual test suite with:
-SenTest UnitTestClassName
or an individual test case with:
-SenTest UnitTestClassName/testMethodName
--corbin
>
> But then the new Xcode 2.1 test bundle won't be loaded into your
> app so no tests will run. Is there a recommended way of debugging
> with Xcode 2.1's test bundles?
>
> The new bundles are nice because you don't have to link your app
> against the testing framework and none of the test code ends up in
> your deployed app.
-
On Jun 20, 2005, at 4:57PM, Corbin Dunn wrote:
> You simply use "otest" as the host to run your application.
> Steps:
> 1. Add a new executable to your project -- select otest in /
> Developer/Tools/otest
> 2. Double click on the executable, and add two run params:
> a. -SenTest Self
> b. $(BUILT_PRODUCTS_DIR)/YourBundleName.octest
>
> This makes it REALLY easy to debug OCUnit tests. You can debug an
> individual test suite with:
>
> -SenTest UnitTestClassName
>
> or an individual test case with:
>
> -SenTest UnitTestClassName/testMethodName
But that only loads the test bundle, not your application. So it
fails to find any of the classes you are testing. At least that's
what happened to me...
-Frank
------------------------------------
Frank M. Midgley
<knarf...>
http://homepage.mac.com/knarf/ -
On Jun 20, 2005, at 6:01PM, Corbin Dunn wrote:
>> I was able to hack this up by testing for -SenTest in the
>> arguments in main() and then manually loading the bundle and
>> testing framework.
>> I was hoping Xcode/OCUnit would be able to do this for me.
>>
>
> It will do it. Just use otest as your host to run your bundle.
Still not working. Setup for debugging unit tests:
Unit testing bundle target (with default build script disabled so it
doesn't run during build)
Contains unit test classes but NO classes from the app.
Application target dependent on unit test target (opposite of build-
time dependency)
Custom executable:
Executable path: "/Developer/Tools/otest"
Arguments: "-SenTest Self $(BUILT_PRODUCTS_DIR)/TestBundle.octest"
Active target: app target
Active executable: custom executable
When this is debugged otest crashes the first time that one of the
unit test classes tries to alloc/init one of the classes from the
app. Since those classes were never loaded this isn't too surprising.
This setup worked fine when building (with the unit test target
dependent on the app and the script enabled) once I set the Test Host
to be the app. It's just when you want to go debug one of the failed
tests that it's a problem.
It looks like the script (/Developer/Tools/RunUnitTests) handles
injecting the bundle into your app so that the classes can co-exist
during the build-time testing. The hack I put together effectively
does this in the debug case but I'd prefer to use built-in
functionality if it's available.
-Frank
------------------------------------
Frank M. Midgley
<knarf...>
http://homepage.mac.com/knarf/ -
On Jun 20, 2005, at 2:47 PM, Frank Midgley wrote:
> But then the new Xcode 2.1 test bundle won't be loaded into your
> app so no tests will run. Is there a recommended way of debugging
> with Xcode 2.1's test bundles?
Here's something I wrote up on just this issue for the Xcode-Users list:
You'll need to set up your application executable in Xcode to support
this. You'll need to specify an argument and two environment
variables. You can do this by highlighting your application in the
Executables group of your Xcode project and getting info on it.
The argument you'll need to specify is "-SenTest All" - this
indicates to the testing framework that it should run all tests.
The environment variables you'll need to specify are
DYLD_INSERT_LIBRARIES and XCInjectBundle. You use
DYLD_INSERT_LIBRARIES to force a helper library we've supplied to
load into your application when it's launched. XCInjectBundle gives
that library the path to a bundle of unit tests to load. Here's how
you should set them:
DYLD_INSERT_LIBRARIES=/System/Library/PrivateFrameworks/
DevToolsBundleInjection.framework/DevToolsBundleInjection
XCInjectBundle=$(BUILT_PRODUCTS_DIR)/YourTestBundleName.octest
Once you do this, you should be able to set breakpoints in your unit
tests and then launch your application under the debugger. (Be sure,
of course, to use "Debug" rather than "Build & Debug" so you aren't
prevented from running under the debugger by unit test failures
during build.)
Hope this helps!
-- Chris
