SenTestingKit fails when using CG-Only

  • Hi,

    I recently tried to get my test rig up and running in leopard, and my
    framework has been using GC only for a while now.
    Setting up a custom executable to call otest on my test bundle,
    causese the following error:

    2007-11-10 01:54:43.694 otest[26142:813] Error loading /Volumes/Builds/
    Debug/MyApplicationKitUnitTest.octest/Contents/MacOS/
    MyApplicationKitUnitTest:  dlopen(/Volumes/Builds/Debug/
    MyApplicationKitUnitTest.octest/Contents/MacOS/
    MyApplicationKitUnitTest, 265): no suitable image found.  Did find:
    /Volumes/Builds/Debug/MyApplicationKitUnitTest.octest/Contents/MacOS/
    MyApplicationKitUnitTest: GC capability mismatch
    2007-11-10 01:54:43.768 otest[26145:203] *** NSTask: Task create for
    path '/Volumes/Builds/Debug/MyApplicationKitUnitTest.octest/Contents/
    MacOS/MyApplicationKitUnitTest' failed: 8, "Exec format error".
    Terminating temporary process.
    2007-11-10 01:54:43.860 otest[26145:203] Usage: otest [-SenTest Self |
    All | None | <TestCaseClassName/testMethodName>] <path of unit to be
    tested>
    2007-11-10 01:54:43.860 otest[26145:203] *** -[NSConcreteTask
    terminationStatus]: task not launched

    When I compile the framework test unit to use -fobjc instead of -fobj-
    c-only testing works as normal.......

    Is this known, and if so, is there a workaround? If I have an app, and
    want to test a critical section, that uses only GC.... how can I
    accomplish that if SenTestingKit is gonna barf every time I throw GC-
    Only objects at it?

    Any help would be appreciated

    Andre
  • On Nov 9, 2007, at 9:07 AM, <listposter...> wrote:

    > I recently tried to get my test rig up and running in leopard, and
    > my framework has been using GC only for a while now.
    > Setting up a custom executable to call otest on my test bundle,
    > causese the following error:

    > Is this known, and if so, is there a workaround? If I have an app,
    > and want to test a critical section, that uses only GC.... how can I
    > accomplish that if SenTestingKit is gonna barf every time I throw GC-
    > Only objects at it?

    The SenTestingKit.framework included with Xcode 3.0 is built GC-
    supported, so it's not at fault.  However, the otest test rig that
    runs unit test bundles for frameworks is *not* built GC-supported in
    Xcode 3.0.

    To run tests for your framework, you'll need to build your own test
    rig, and then tell Xcode to use it in otest's place.

    You should be able to build your own test rig by just creating a
    simple command-line tool that links Cocoa.framework and
    SenTestingKit.framework, sets the SenTestTool user default in the
    registration domain to YES (which indicates to the framework that a
    test tool is being used), and then calls through to SenSelfTestMain.
    The SenTestTool user default and SenSelfTestMain function are declared
    in <SenTestingKit/SenTestProbe.h>.

    To tell Xcode to use your test rig instead of otest, just set the
    OTEST build setting to the path to your test rig.

      -- Chris
  • On Nov 9, 2007, at 3:37 PM, Chris Hanson wrote:

    > On Nov 9, 2007, at 9:07 AM, <listposter...> wrote:
    >
    >> I recently tried to get my test rig up and running in leopard, and
    >> my framework has been using GC only for a while now.
    >> Setting up a custom executable to call otest on my test bundle,
    >> causese the following error:
    >
    >> Is this known, and if so, is there a workaround? If I have an app,
    >> and want to test a critical section, that uses only GC.... how can
    >> I accomplish that if SenTestingKit is gonna barf every time I throw
    >> GC-Only objects at it?
    >
    > The SenTestingKit.framework included with Xcode 3.0 is built GC-
    > supported, so it's not at fault.  However, the otest test rig that
    > runs unit test bundles for frameworks is *not* built GC-supported in
    > Xcode 3.0.
    >
    > To run tests for your framework, you'll need to build your own test
    > rig, and then tell Xcode to use it in otest's place.
    >
    > You should be able to build your own test rig by just creating a
    > simple command-line tool that links Cocoa.framework and
    > SenTestingKit.framework, sets the SenTestTool user default in the
    > registration domain to YES (which indicates to the framework that a
    > test tool is being used), and then calls through to
    > SenSelfTestMain.  The SenTestTool user default and SenSelfTestMain
    > function are declared in <SenTestingKit/SenTestProbe.h>.
    >
    > To tell Xcode to use your test rig instead of otest, just set the
    > OTEST build setting to the path to your test rig.
    >

    I also had to recompile the framework; otherwise, it'd link and run,
    but no tests were executed.

    Anyone testing please make sure to file a defect.  It's ridicules to
    have to jump through these hoops to be able to test.  You wouldn't
    tolerate compiling your own gcc to support gc.
  • On Nov 9, 2007, at 1:55 PM, Timothy Reaves wrote:

    > I also had to recompile the framework; otherwise, it'd link and
    > run, but no tests were executed.

    Thanks for letting me know.  I know you were one of the people I
    provided with the same instructions I gave Andre about this case, but
    I haven't yet heard back about whether those instructions worked.

    > Anyone testing please make sure to file a defect.  It's ridicules
    > to have to jump through these hoops to be able to test.  You
    > wouldn't tolerate compiling your own gcc to support gc.

    Please understand that all work is prioritized, and that sometimes the
    priorities may not be what you want them to be for a variety of
    reasons.  You're certainly welcome to disagree with the
    prioritization, but remember that you'll attract more flies with honey
    than with vinegar; there's no need to be insulting in your disagreement.

    Also, please understand that OCUnit as shipped with Xcode 3.0 **does
    work** for GC-supported frameworks, and **does work** for both GC-
    supported and GC-required applications.  It's **only** the case of GC-
    required framework tests that OCUnit as shipped with Xcode 3.0 does
    not work.  Here's the current compatibility matrix as of Xcode 3.0:

                            test framework  test application
            GC unsupported  works          works
            GC supported    works (non-GC)  works (GC)
            GC required    broken          works (GC)

    There are already several bugs filed against Xcode about this, so we
    don't really need any more; the problem and its solution are both well-
    understood.  (Obviously I can't say anything more than that about
    future products or product plans, so please bear with me.)

    I've requested ADC provide the same workaround to others as I gave
    Andre earlier in the thread; however, I have not heard back from
    anyone about whether it has not worked for them.  Your input above is
    valuable in that it sounds like the instructions I provided *don't*
    work (though they should have).

    In the meantime, you should be able to use the following code in a
    tool that links against Cocoa and SenTestingKit.  Then you should be
    able to specify the path to that tool in the OTEST build setting for
    your unit test bundle target, and use it to run tests successfully
    against GC-required frameworks.  Please, anyone who tries it, let me
    know if it works for you.  (Note: This was typed in Mail, so there may
    be typos, but the overall logic should be correct.  What's critical is
    specifying the right user defaults -- all of which are in
    SenTestProbe.h -- and then invoking +[SenTestProbe runTests:].)

      -- Chris Hanson
          Development Technologies
          Apple

    #import <Cocoa/Cocoa.h>
    #import <SenTestingKit/SenTestingKit.h>

    @interface SenTestProbe (InternalMethods)
    - (void)runTests:(id)ignored;
    @end

    int main(int argc, char **argv) {
        NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];

        // Tell SenTestingKit to use our last argument as the test
    bundle, to
        // run all the tests it can find, and that the executable is
    equivalent
        // to the otest test rig supplied with OCUnit.

        NSDictionary *testDefaults = [NSDictionary
    dictionaryWithObjectsAndKeys:
            [[[NSProcessInfo processInfo] arguments] lastObject],
    SenTestedUnitPath,
            SenTestScopeAll, SenTestScopeKey,
            [NSNumber numberWithBool:YES], SenTestToolKey,
            nil];
        [[NSUserDefaults standardUserDefaults]
    registerDefaults:testDefaults];

        // Run the tests based on the defaults set above.
        // It will invoke exit() with an appropriate value as well.

        [SenTestProbe runTests:nil];

        [pool drain];
        return 0;
    }
  • On $BJ?@.(B 19/11/10, at 11:19, Chris Hanson wrote:
    > On Nov 9, 2007, at 1:55 PM, Timothy Reaves wrote:
    >
    >> I also had to recompile the framework; otherwise, it'd link and
    >> run, but no tests were executed.
    >
    > Thanks for letting me know.  I know you were one of the people I
    > provided with the same instructions I gave Andre about this case,
    > but I haven't yet heard back about whether those instructions worked.
    >
    >> Anyone testing please make sure to file a defect.  It's ridicules
    >> to have to jump through these hoops to be able to test.  You
    >> wouldn't tolerate compiling your own gcc to support gc.
    >
    > Please understand that all work is prioritized, and that sometimes
    > the priorities may not be what you want them to be for a variety of
    > reasons.  You're certainly welcome to disagree with the
    > prioritization, but remember that you'll attract more flies with
    > honey than with vinegar; there's no need to be insulting in your
    > disagreement.
    >
    > Also, please understand that OCUnit as shipped with Xcode 3.0 **does
    > work** for GC-supported frameworks, and **does work** for both GC-
    > supported and GC-required applications.  It's **only** the case of
    > GC-required framework tests that OCUnit as shipped with Xcode 3.0
    > does not work.  Here's the current compatibility matrix as of Xcode
    > 3.0:
    >
    > test framework  test application
    > GC unsupported  works          works
    > GC supported    works (non-GC)  works (GC)
    > GC required    broken          works (GC)
    >
    > There are already several bugs filed against Xcode about this, so we
    > don't really need any more; the problem and its solution are both
    > well-understood.  (Obviously I can't say anything more than that
    > about future products or product plans, so please bear with me.)
    >
    > I've requested ADC provide the same workaround to others as I gave
    > Andre earlier in the thread; however, I have not heard back from
    > anyone about whether it has not worked for them.  Your input above
    > is valuable in that it sounds like the instructions I provided
    > *don't* work (though they should have).
    >
    > In the meantime, you should be able to use the following code in a
    > tool that links against Cocoa and SenTestingKit.  Then you should be
    > able to specify the path to that tool in the OTEST build setting for
    > your unit test bundle target, and use it to run tests successfully
    > against GC-required frameworks.  Please, anyone who tries it, let me
    > know if it works for you.  (Note: This was typed in Mail, so there
    > may be typos, but the overall logic should be correct.  What's
    > critical is specifying the right user defaults -- all of which are
    > in SenTestProbe.h -- and then invoking +[SenTestProbe runTests:].)
    >
    > -- Chris Hanson
    > Development Technologies
    > Apple

    Chris, thanks for your help.
    I have the custom executable set up, as you said.
    There were/are some problems though.

    1.) Building the tool and linking to the SenTestingKit framework
    causes the tool to fail at launch with the following error:
    dyld: Library not loaded: @rpath/SenTestingKit.framework/Versions/A/
    SenTestingKit
      Referenced from: /Volumes/Builds/Release/CGFrameWorkOtest
      Reason: image not found

    The solution, is to place the SenTestingKit.framework folder into any
    one of the Library/Frameworks directories. But, that causes another
    problem......

    2.) When running the custom test rig, it tests the linked-in
    sentesting frramework! As follows:

    macbook:~ andre$ /Volumes/Builds/Release/CGFrameWorkOtest -SenTest
    All /Volumes/Builds/Debug/ApplicationKitAdditionsUnitTest.octest
    Test Suite 'All tests' started at 0019-11-10 12:37:04 +0900
    Test Suite '/Users/andre/Library/Frameworks/
    SenTestingKit.framework(Tests)' started at 0019-11-10 12:37:04 +0900
    Test Suite 'SenInterfaceTestCase' started at 0019-11-10 12:37:04 +0900
    Test Suite 'SenInterfaceTestCase' finished at 0019-11-10 12:37:04 +0900.
    Executed 0 tests, with 0 failures (0 unexpected) in 0.000 (0.000)
    seconds

    Test Suite '/Users/andre/Library/Frameworks/
    SenTestingKit.framework(Tests)' finished at 0019-11-10 12:37:04 +0900.
    Executed 0 tests, with 0 failures (0 unexpected) in 0.000 (0.001)
    seconds

    Test Suite 'All tests' finished at 0019-11-10 12:37:04 +0900.
    Executed 0 tests, with 0 failures (0 unexpected) in 0.000 (0.003)
    seconds

    Instead of copying the framework to my library folder, I tried the
    following:

    I've set both LD_RUNPATH_SEARCH_PATHS and FRAMEWORK_SEARCH_PATHS to: "$
    (DEVELOPER_FRAMEWORKS_DIR)" with no avail.......

    ........ I know I must be missing something.

    Andre

    >
    >
    > #import <Cocoa/Cocoa.h>
    > #import <SenTestingKit/SenTestingKit.h>
    >
    > @interface SenTestProbe (InternalMethods)
    > - (void)runTests:(id)ignored;
    > @end
    >
    > int main(int argc, char **argv) {
    > NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
    >
    > // Tell SenTestingKit to use our last argument as the test
    > bundle, to
    > // run all the tests it can find, and that the executable is
    > equivalent
    > // to the otest test rig supplied with OCUnit.
    >
    > NSDictionary *testDefaults = [NSDictionary
    > dictionaryWithObjectsAndKeys:
    > [[[NSProcessInfo processInfo] arguments] lastObject],
    > SenTestedUnitPath,
    > SenTestScopeAll, SenTestScopeKey,
    > [NSNumber numberWithBool:YES], SenTestToolKey,
    > nil];
    > [[NSUserDefaults standardUserDefaults]
    > registerDefaults:testDefaults];
    >
    > // Run the tests based on the defaults set above.
    > // It will invoke exit() with an appropriate value as well.
    >
    > [SenTestProbe runTests:nil];
    >
    > [pool drain];
    > return 0;
    > }
previous month november 2007 next month
MTWTFSS
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30    
Go to today