How do you debug unit test in Xcode 3?

I followed Apple instructions to set up Unit Testing in my project. I followed the instructions to make them dependent, so the tests run with every build of my main project. This works, and when my tests pass, the application starts; when they do not, I get build errors in the rows of failed tests.

I would like, however, to be able to execute my application code when the tests fail, but cannot properly configure Xcode (3.2.5). The project is a Mac project, not iOS.

I tried the instructions here and here , but the execution never stopped at the breakpoints that I set, neither in the unit test code nor in my application code. After executing the first set of instructions, the breakpoints that I set turned yellow with blue outlines, and I also don't know what that means. What do I need to do to complete my tests?

Update

I found another page trying to solve this problem ( here ) by adding arguments and environment variables to my main executable, but again, Do not force execution to stop at my breakpoints. I also noticed that my test (log) log statements also do not appear in my debugger console.

I also found out that yellow breakpoints mean that code cannot be found at runtime. This is in my test case class, so it definitely seems like they explain why they don't shoot.

+5
source share
5 answers

The only thing that worked for me in the end was upgrading to Xcode 4. It blends perfectly. There was a bit of pain moving on to it, but now that this is happening, the integration is great. I am fully able to run my tests and application code.

0
source

Usually I have no problem debugging OCTest tests with Xcode 3.2, including stopping at breakpoints.

- gdb, otest . , /Developer/Tools/otest Xcode, OCTest ( " Active Executable otest" "" ), Foo.octest , Foo).

, , ( , , , ). , , , YES, ( "" ), otest , , .

, - , - , , , - , . , , , NSLog Xcode. bin , , , . , , ( ​​ ?).

+2

, Hiedi Utley http://hiediutley.wordpress.com/2011/03/08/xcode3-debugging-ios-unit-tests/. , , - unit test bundle, Run Script , , . Get Info Run Script "Run Script " , .

Hiedi , LogicTestsGDB. :

"":

  • : Developer/usr/bin/otest ( /)
  • : Relative to Current SDK
  • : Build Products directory

"":

  • : UnitTest (, LogicTests.octest)
  • ,
    • DYLD_LIBRARY_PATH ... : ${BUILD_PRODUCTS_DIR}:${DYLD_LIBRARY_PATH}
    • DYLD_FRAMEWORK_PATH . : ${SDKROOT}/Developer/Library/Frameworks
    • DYLD_ROOT_PATH ...... : ${SDKROOT}
    • IPHONE_SIMULATOR_ROOT : ${SDKROOT}
    • OBJC_DISABLE_GC : YES
    • DYLD_NEW_LOCAL_SHARED_REGIONS : YES
    • DYLD_NO_FIX_PREBINDING : YES
    • CFFIXED_USER_HOME : ${HOME}/Library/Application Support/iPhone Simulator/

. , ,

  • Run Script.
  • Script
  • Active Target unit test (, LogicTests.octest).
  • Active Executable (, LogicTestsGDB)
  • " "

, :

  • Run Script.
  • Run Script
  • Active Target
  • Active Executable

, AppleScript Script, :

property kApplicationName : "MyApp" -- name of the normal application to build
property kUnitTestName : "LogicTests" -- name of the bundle target to debug
property kUnitTestRunner : "LogicTestGDB" -- name of the executable to use when debugging the unit test bundle

tell application "Xcode"
    tell the active project document
    set theTarget to first target whose name is kUnitTestName
        set thePhase to first run script phase of theTarget
        if name of active target is kApplicationName then
            set active target to theTarget
            set theExecutable to first executable whose name is kUnitTestRunner
            set active executable to theExecutable
            set run only when installing of thePhase to true
        else
            set theTarget to first target whose name is kApplicationName
            set active target to theTarget
            set theExecutable to first executable whose name is kApplicationName
            set active executable to theExecutable
            set run only when installing of thePhase to false
        end if
        return "Targeting " & (name of active executable)
    end tell
end tell
+2

develop your unit tests so that they wrap the program that is in the project with the target goal, and then just open the dependent project and work in it. this is most likely a project with a library and an executable file that calls through the library (2 goals). then you can simply open the project and debug, while your unit tests depending on this will call this library. this is a more modular approach.

luck

0
source

All Articles