OCUnit测试一个嵌入式框架 [英] OCUnit testing an embedded framework

查看:180
本文介绍了OCUnit测试一个嵌入式框架的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

更新:我最终放弃了,并添加了GHUnit到我的项目。



更新:您可以在这里下载Xcode项目: http://github.com/d11wtq/Cioccolata



我添加了单元测试目标到我的Xcode项目,但它无法找到我的框架,当它生成,说:



Test.octest无法加载,因为发生链接错误。 dyld可能找不到测试包所链接的框架框架或库,可能是因为框架或库在链接时有不正确的安装路径。



我的框架(主要项目目标)被设计为嵌入式的,因此具有 @executable_path /../ Frameworks 的安装路径。 / p>

我将框架标记为测试目标的直接依赖,并将其添加到链接二进制库与库构建阶段。



此外,我添加了复制文件的第一步(在它构建依赖关系之后),它将框架复制到单元测试包的Frameworks目录。



任何人都有这方面的经验吗?我不知道我错过了什么。



编辑|我确定我不应该,因为一个框架是不可执行的,但我没有设置测试主机和捆绑加载程序。这应该(对我的理解)一切都确定,因为测试捆绑链接到框架,将加载它就像任何其他捆绑。



编辑|我想我就在那里。我阅读了以下文章,其中规定使用@rpath而不是@executable_path。



http://www.dribin.org/dave/blog/archives/2009/11/15/rpath/



在这种情况下,它是完全有意义的,因为OCUnit测试包不是一个可执行文件,它是一个普通的老包,所以@executable_path不兼容。所以现在我的框架的安装目录设置为 @rpath ,测试目标的运行时搜索路径(rpath)定义为构建目录。这节省了我不得不将框架复制到测试包,意味着整体的结果框架是更灵活的性质,因为它可以住在任何地方。



现在,我也意识到我应该在测试目标上设置了Bundle Loader,所以现在设置为框架二进制文件的路径。



I可以构建测试目标,我可以从框架#import类,无错误。但是,一旦我尝试从框架实例化一个类,我得到以下错误:



/Developer/Tools/RunPlatformUnitTests.include:412 :note注意:对于架构'i386'(GC OFF)运行测试
objc [50676]:GC:forcing的结构体系结构'i386'的启动测试:
/Developer/Tools/RunPlatformUnitTests.include:419: GC OFF,因为OBJC_DISABLE_GC已设置
测试套件'/Users/chris/Projects/Mac/Cioccolata/build/Debug/Test.octest(Tests)'从2010-05-21 12:53:00开始+1000
Test Suite'CTRequestTest'从2010-05-21 12:53:00开始+1000
测试用例' - [CTRequestTest testNothing]'开始。
/Developer/Tools/RunPlatformUnitTests.include:line 415:50676总线错误$ {THIN_TEST_RIG}$ {OTHER_TEST_FLAGS}$ {TEST_BUNDLE_PATH}
/Developer/Tools/RunPlatformUnitTests.include: 451:错误:测试/'Developer / Tools / otest'与代码138异常退出(它可能已崩溃)。
命令/ bin / sh失败,退出代码1



我的测试方法没有什么比分配和随后释放一个HelloWorld类我创建了帮助调试此设置:

   - (void)testNothing {
CTHelloWorld * h = [[CTHelloWorld alloc ] 在里面];
[h release];
}



如果我将这些代码替换为 STAssertTrue (YES,@Testing nothing); 即使类仍在导入,错误消失。

解决方案

由于没有其他人介入这个问题,我会结束,说SenTestingKit真的没有压抑我的复杂性(和丑陋)的设置为我的需要。我强烈推荐GHUnit运行在UI(或者在命令行,如果你喜欢),并支持使用gdb开箱即用。在我的项目中下载并使用GHUnit需要花费几分钟。



很漂亮。苹果应该用Xcode而不是SenTestingKit IMHO。


UPDATE: I ended up giving up and added GHUnit to my project instead. I got up and running with GHUnit in a matter of minutes.

UPDATE: You can download the Xcode project here: http://github.com/d11wtq/Cioccolata

I've added a Unit Test target to my Xcode project but it fails to find my framework when it builds, saying:

Test.octest could not be loaded because a link error occurred. It is likely that dyld cannot locate a framework framework or library that the the test bundle was linked against, possibly because the framework or library had an incorrect install path at link time.

My framework (the main project target) is designed to be embedded and so has an install path of @executable_path/../Frameworks.

I've marked the framework as a direct dependency of the test target and I've added it to the "Link Binary with Libraries" build phase.

Additionally I've add a first step (after it's built the dependency) of "Copy Files" which simply copies the framework to the unit test bundle's Frameworks directory.

Anyone got any experience on this? I'm not sure what I've missed.

EDIT | I'm pretty sure I'm not supposed to, since a framework is not executable, but I haven't set "Test Host" and "Bundle Loader". This should (to my understanding) all be ok since the test bundle is linked against the framework and will load it just like any other bundle.

EDIT | I think I'm nearly there. I read the following article which dictates the use of @rpath instead of @executable_path.

http://www.dribin.org/dave/blog/archives/2009/11/15/rpath/

In this case it makes perfect sense since the OCUnit test bundle is NOT an executable, it's a plain old bundle, so @executable_path is not compatible. So now my framework has its installation directory set to @rpath and the Test target has its runtime search paths (rpath) defined as the build directory. This saves me having to copy the framework into the test bundle and means that overall the resulting framework is much more flexible in nature since it can live anywhere.

Now, I also realize that I should have set the Bundle Loader on the Test target, so this is now set to the path of the framework binary.

I can build the test target and I can #import classes from the framework, error free. But as soon as I try to instantiate a class from the framework I get the following error:

/Developer/Tools/RunPlatformUnitTests.include:412: note: Started tests for architectures 'i386' /Developer/Tools/RunPlatformUnitTests.include:419: note: Running tests for architecture 'i386' (GC OFF) objc[50676]: GC: forcing GC OFF because OBJC_DISABLE_GC is set Test Suite '/Users/chris/Projects/Mac/Cioccolata/build/Debug/Test.octest(Tests)' started at 2010-05-21 12:53:00 +1000 Test Suite 'CTRequestTest' started at 2010-05-21 12:53:00 +1000 Test Case '-[CTRequestTest testNothing]' started. /Developer/Tools/RunPlatformUnitTests.include: line 415: 50676 Bus error "${THIN_TEST_RIG}" "${OTHER_TEST_FLAGS}" "${TEST_BUNDLE_PATH}" /Developer/Tools/RunPlatformUnitTests.include:451: error: Test rig '/Developer/Tools/otest' exited abnormally with code 138 (it may have crashed). Command /bin/sh failed with exit code 1

My test method does nothing more than allocate and subsequently release a HelloWorld class I created to help debug this setup:

- (void)testNothing {
    CTHelloWorld *h = [[CTHelloWorld alloc] init];
    [h release];
}

If I replace these lines of code with an STAssertTrue(YES, @"Testing nothing"); the error goes away, even though the class is still being imported.

解决方案

Since nobody else has chimed into this question, I'll finish off by saying SenTestingKit really unimpressed me with the complexity (and ugliness) of the setup for my needs. I highly recommend GHUnit which runs in a UI (or on command line if you prefer) and supports using gdb out of the box. It took me a matter of minutes to download and use GHUnit in my project.

It's pretty too. Apple should ship it with Xcode instead of SenTestingKit IMHO.

这篇关于OCUnit测试一个嵌入式框架的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆