Cocoa Xcode 3.1.3问题单元测试插件

继ChrisHanson和Apple的博客之后，我开始为我的项目实施单元测试。然而，我使用了很多插件（可加载的捆绑包），我不知道如何测试它们
我想我会使用Chris Hanson描述的测试框架的方法。 我从一个Cocoa Bundle项目开始，添加了一个principal类，并将类型更改为plugin。
然后我添加了单元测试包，将插件添加为直接依赖项（苹果的说明），并设置以下构建设置：

捆绑加载程序：$（内置产品目录）/CocoaPlugin.plugin/Contents/MacOS/CocoaPlugin
测试主机：$（BUNDLE\u LOADER）

问题是，一旦我完成了这项工作并构建了测试目标，我就会收到以下消息：

错误：测试主机“/Users/elisevanlooij/Documents/plugins/CocoaPlugin/build/debugcoaplugin.plugin/Contents/MacOS/CocoaPlugin”异常退出，代码127（可能已崩溃）。[另一个插件中的代码126]

---

我曾希望添加otest自定义可执行文件会有所帮助，但不幸的是没有。我真的希望有人能帮助我，因为无法对我的插件进行单元测试，这真的会让我的测试生活陷入困境。

退一步。您的包加载程序设置错误，添加自定义可执行文件不会影响单元测试包的编译

您需要让您的单元测试包在没有错误（和警告！）的情况下进行构建，并且您的测试将自动运行（您至少有一个有效的SenTestCase类和至少一个有效的测试方法，对吗？）

所以， 您是说您的测试包编译时没有警告，并且您已经使用插件中的类和方法编写了一些测试？如果是这样的话，您必须知道如何将插件包加载到单元测试包中并定义某种API，因为插件包没有任何公共头，对吗

将插件加载到插件中（基本上是您正在尝试做的事情）并不容易，而且它们在编译时不会像您提到的Chris Hanson博客中的框架那样神奇地“链接”。如果它们是插件，它们就不会是插件

最简单的方法是根本不测试插件，而是将要测试的文件直接添加到单元测试包中。至少通过这种方式，您可以继续测试代码，而不必费劲地动态加载捆绑包

但是，如果这不令人满意，您可以通过一点努力来完成您正在尝试的工作-您肯定应该添加测试来验证您的插件是否已加载，以及您认为可用的符号是否确实可用。一旦您的测试构建正常，您应该关注Chris Hanson的另一篇优秀博客，该博客向您展示了如何在调试器中单步执行测试，您应该能够跟踪任何错误

你的

捆绑加载程序：$（内置产品目录）/CocoaPlugin.plugin/Contents/MacOS/CocoaPlugin

这是正确的。这意味着当 链接您的测试包时，您不包括测试中的类，它们将 从CocoaPlugin中查找。这是一个编译时设置，应该会导致测试失败 捆绑以成功编译/链接。（请参阅中的-bundle_loader）

你的

测试主机：$（BUNDLE\u加载程序）

这是不正确的。您的测试主机应该是应用程序（从main方法调用了NSApplicationMain）或未设置。此测试主机设置是运行单元测试的运行时设置。您基本上有两种选择：

• 不要设置TEST_主机，从测试包中加载插件。例如，您可以使用initlaize方法来实现这一点

• 创建一个虚拟的测试主机应用程序来加载你的插件，然后调用NSApplicationMain，并将此应用程序用作你的测试主机

用于加载插件的测试包的

+initalize

方法如下所示：

+ (void)initialize
{
    NSBundle* bundle = [NSBundle bundleWithPath:pathToPlugin];
    [bundle load];
    NSLog(@"Loaded:%@\n",bundle);
}

int main(int argc,const char** argv)
{
  NSBundle* bundle = [NSBundle bundleWithPath:pathToPlugin];
  [bundle load];
  NSLog(@"Loaded:%@\n",bundle);
  return NSApplicationMain(argc,argv);
}

虚拟测试主机应用程序中的主要方法如下所示：

+ (void)initialize
{
    NSBundle* bundle = [NSBundle bundleWithPath:pathToPlugin];
    [bundle load];
    NSLog(@"Loaded:%@\n",bundle);
}

int main(int argc,const char** argv)
{
  NSBundle* bundle = [NSBundle bundleWithPath:pathToPlugin];
  [bundle load];
  NSLog(@"Loaded:%@\n",bundle);
  return NSApplicationMain(argc,argv);
}

测试插件的其他想法：

• 使用独立的bundle：不要指定bundle\u LOADER或TEST\u HOST，也不要将插件中的类放入unittest bundle中
• 将您的测试用例放入插件，并尝试获取unittest。只需在插件中添加一个脚本阶段：

  TEST\u RIG=/Developer/Tools/otest“${SYSTEM\u Developer\u DIR}/Tools/RunUnitTests”

---

尽管将otest添加为自定义可执行文件不起作用，但它确实帮助我改进了工作流程。现在，我添加了一个程序，将我正在处理的插件合并为一个自定义可执行文件，这样每当我构建并运行我的插件时（在Xcode中，这是一个动词），程序也会启动并运行我的插件。节省了大量的来回切换。在这个方向的某个地方，我的问题的答案也可能存在。谁知道呢？恩，赏金的事时间不多了。我学到了很多，觉得我离答案更近了，但坦率地说，我还没有有效的解决方案，也不知道什么时候能找到答案。两个人，而不是我，已经获得了第一个答案分数，所以悬赏将默认为jib，祝贺你。回答很长，但不知怎么的，我觉得我们在这里有点矛盾。我的插件加载和工作良好，但我想找到一种方法来单元测试它们的内部工作。这正是我无法接受的指示，包括汉森先生优秀的博客。问题是，对于加载程序来说，插件是一个黑盒子，调试器无法进入。因此，单元测试必须与插件一起加载，但是如何加载呢？如果您真的不想像我建议的那样将插件类直接编译到单元测试包中，您需要查看+（NSBundle*）bundleWithPath:（NSString*）fullPath，以确保在运行时从单元测试包加载插件代码。插件的任何内容都不意味着你不能“进入”调试器。不清楚你是否写过信