| Folks,
Everyone has got their favorite "I cannot believe the folks at Apple didn't fix/deal with issue Y in Xcode...". Mine is unit tests and the debugging of unit tests. I've reviewed this document again:
but I still don't see any information that pertains to debugging unit tests. For months, we struggled under Xcode 3.1.x with a hacked workaround that involved creating a separate empty project, starting the debugger in that project, killing the executable and calling 'attach waitfor otest' and then starting the tests from our original iPhone project. This method involved endless shortcomings such as missing symbol information, breakpoints not always being hit, long turnaround times in the run/debug cycle, endlessly switching back and forth between project windows while debugging, etc, etc.
I filed an issue some time ago with DTS, and they gave me a procedure to debug unit tests from within our original project which was not too onerous and had the added advantage of being able to run and debug just one test class instead of having to run the entire suite. The steps were as follows:
How you debug the test depends on where it's running. You can debug simulator tests by creating a custom executable that uses "otest" executable (typically "/Developer/Tools/otest"), with arguments specifying your tests and bundle. For example, to run all tests in TestBundle, you'd have arguments:
-SenTest All $(BUILT_PRODUCTS_DIR)/TestBundle.octest
For this to work you will have to set some custom environment variables.
o DYLD_ROOT_PATH to "$(SDKROOT)"
o DYLD_FRAMEWORK_PATH to "$(BUILT_PRODUCTS_DIR):$(DEVELOPER_DIR)/Library/Frameworks:$(DYLD_FRAMEWORK_PATH)"
o IPHONE_SIMULATOR_ROOT to "$(SDKROOT)"
o CFFIXED_USER_HOME to "$(HOME)/Library/Application Support/iPhone Simulator/User/"
o OBJC_DISABLE_GC to "YES"
You also have to set the working directory to the project directory (in the General tab of the executable info window).
With these settings in place, you can set breakpoints in your unit test code and debug it by choosing "Build and Debug" from the Debug menu.
Unfortunately, this is now broken in Xcode 3.2.1. I get the following error when trying to run the tests:
dyld: Symbol not found: _SCDynamicStoreCreate
Referenced from: /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices
Expected in: /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator3.1.3.sdk/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit
in /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices
DTS is telling me that this is a bug, and they are investigating a workaround.
In the meantime, I am absolutely dying here. I spent literally 30 seconds fixing some code that had a bug and then 6 hours trying to debug a silly problem in my unit tests that should have revealed this bug that I was trying to fix. Part of my time was wasted in trying to work around the above error, but the rest of the time was consumed with the old unreliable debugging methodology that arises from attaching to a process and having to run our full unit test suite to debug just one test in particular.
Some may argue that this is why you shouldn't bother with unit testing, because it consumes too much time for too little benefit. I won't go into that argument here, except to say that we don't have these problems in the Java world using other IDEs.
I would like to ask two things in this forum: 1) Does anyone know of a workaround to my problem besides the one that I already have that involves attaching to the unit tests and 2) Are these problems with debugging unit tests isolated to iPhone or does everyone suffer under this?
Regards, Paul |