OCUnit 测试嵌入式框架
更新：我最终放弃了并将 GHUnit 添加到我的项目中。我在几分钟内就启动并运行了 GHUnit。
更新：您可以在此处下载 Xcode 项目： http://github.com/d11wtq/Cioccolata
我已将单元测试目标添加到我的 Xcode 项目中，但在构建时无法找到我的框架，并显示：
Test.octest 无法加载，因为发生链接错误。 dyld 可能无法找到测试包所链接的框架或库，可能是因为该框架或库在链接时的安装路径不正确。
我的框架（主项目目标）是设计的要嵌入，因此安装路径为 @executable_path/../Frameworks。
我已将该框架标记为测试目标的直接依赖项，并将其添加到“将二进制文件与库链接”构建阶段。
此外，我添加了“复制文件”的第一步（在构建依赖项之后），它只是将框架复制到单元测试包的 Frameworks 目录中。
有人有这方面的经验吗？我不确定我错过了什么。
编辑|我很确定我不应该这样做，因为框架不可执行，但我还没有设置“测试主机”和“捆绑加载器”。 （据我理解）这应该没问题，因为测试包是与框架链接的，并且会像任何其他包一样加载它。
编辑|我想我已经快到了。我阅读了以下文章，其中规定使用 @rpath 而不是 @executable_path。
http://www.dribin.org/dave/blog /archives/2009/11/15/rpath/
在这种情况下，它非常有意义，因为 OCUnit 测试包不是可执行文件，它是一个普通的旧包，因此 @executable_path 不兼容。因此，现在我的框架的安装目录设置为 @rpath 并且测试目标的运行时搜索路径 (rpath) 定义为构建目录。这使我不必将框架复制到测试包中，并且意味着总体而言生成的框架本质上更加灵活，因为它可以存在于任何地方。
现在，我还意识到我应该在测试目标上设置捆绑加载器，因此现在将其设置为框架二进制文件的路径。
我可以构建测试目标，并且可以从框架#import 类，不会出现错误。但是，一旦我尝试从框架实例化一个类，就会收到以下错误：
/Developer/Tools/RunPlatformUnitTests.include:412: note: Started tests for Architectures 'i386' /Developer/Tools/RunPlatformUnitTests.include:419: 注意：运行架构“i386”的测试（GC 关闭） objc[50676]：GC：强制 GC 关闭，因为设置了 OBJC_DISABLE_GC 测试套件 '/Users/chris/Projects/Mac/Cioccolata/build/Debug/Test.octest(Tests)' 于 2010-05-21 12:53:00 +1000 开始 测试套件“CTRequestTest”于 2010-05-21 12:53:00 +1000 开始 测试用例“-[CTRequestTest testNothing]”已开始。 /Developer/Tools/RunPlatformUnitTests.include：第 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] init];
[h release];
}
如果我将这些代码行替换为 STAssertTrue(是的，@“不测试任何内容”）；即使仍在导入该类，错误也会消失。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
由于没有其他人回答这个问题，我最后想说的是，SenTestingKit 的设置的复杂性（和丑陋）确实让我印象深刻，无法满足我的需求。我强烈推荐 GHUnit，它在 UI 中运行（如果您愿意，也可以在命令行上运行），并且支持开箱即用地使用 gdb。我花了几分钟的时间下载并在我的项目中使用 GHUnit。
也很漂亮啊Apple 应该将其与 Xcode 一起提供，而不是 SenTestingKit 恕我直言。
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.
我遇到了同样的问题，但是使用 Kiwi 单元测试框架。我的问题是“构建设置”下未设置“测试主机”。当我将其设置为 $(BUNDLE_LOADER) 时，一切正常。使用 Xcode 4.5.2 iOS SDK 6.0 进行验证。
I had the same problem but with Kiwi Unit Testing framework. My problem was that "Test Host" was not set under Build Settings. When I set it to $(BUNDLE_LOADER) everything worked perfectly. Verified using Xcode 4.5.2 iOS SDK 6.0.
这种事在我身上发生过几次。我知道您切换到 GHUnit，但以防万一有人感兴趣：在解决这个问题很长时间之后，我意识到 Xcode 只是没有在目标的编译部分添加代码类（.m 文件），而是在目标的复制资源部分。将其移动到正确的位置解决了问题。
It happened to me a few times. I know you switched to GHUnit, but just in case someone is interested: after going around this for a LONG time I realised that Xcode just didn't add the code classes (.m files) in the Compile part of the target, but in the Copy Resources part of the target. Moving it to the right place solved the issue.
您可能会对以下文章有一些运气，特别是将 DYLD_FRAMEWORK_PATH 和 DYLD_LIBRARY_PATH 添加到可执行文件可能会帮助。
You might have some luck with the following article, in particular adding DYLD_FRAMEWORK_PATH and DYLD_LIBRARY_PATH to your executable might help.
好的，所以我也对此进行了斗争，这就是我发现的问题的简单解决方案：
请注意，这意味着当您想要运行测试时，您只需编译测试包目标即可。
理想，不；有效，是的。
Apple 确实实现了这一自动化操作，并且开箱即用，可以正常工作。
Ok, so I too fought with this, and here is what I have found to be the simple solution to the problem:
Note, this means you simply have to compile your test bundle target when you want to run your tests.
Ideal, no; works, yes.
Apple really automate this and get it working correctly, out of the box.
我确实同意 GHUnit 的建议，它太棒了！
然而，在 Apple 将 OCTest 集成到 xCode4 中后，我转而使用 OCTest，因此我正在努力解决这些问题。
在我们向项目添加新文件后，我发生了此处报告的链接问题。其中包括 ViewController 和 xib，但这些文件在 xcode 中针对应用程序和测试目标进行了标记。我通过检查派生数据目录中的 OCTest 包发现了这些文件。 ~/Library/Developer/Xcode/DerivedData/ 右键单击并从查找器中选择“显示包内容”。寻找不属于那里的东西，即：应用程序类和资源。从“编译源”或“复制捆绑资源”中删除这些文件更正了链接错误。
I do agree with the recommendations for GHUnit, it totally rocks!
However, I've switched to using OCTest after Apple integrated it in xCode4 so I'm trudging through the issues.
The linking problem reported here occurred for me after we added new files to the project. These included ViewControllers and xibs but the files were marked in xcode for both the application and the test target. I discovered the files by inspecting the OCTest bundle in the derived data directory. ~/Library/Developer/Xcode/DerivedData/ Right click and choose "Show Package Contents" from finder. Look for stuff that does not belong there, ie: application classes and resources. Removing these files from the "Compile Sources" or "Copy Bundle Resources" corrected the linking error.