logo标签列表

使用C++/CLI与NUnit的限制

c++-clinunit
8
这篇关于C++单元测试框架的问题答案提出了一个我之前没有想到的可能性：使用C++/CLI和NUnit为本地C++代码创建单元测试。
我们使用NUnit进行C#测试，因此也可以考虑将其用于C++。
我从未使用过托管C++，因此我的担忧是这种方法是否存在任何实际限制？您中有多少人这样做？如果是这样，你们的经验如何？
5个回答
9
我们经常这样做。我们有很多用C++/CLI编写的程序集，并使用C#和NUnit对其进行测试。实际上，由于我们的目标是提供能够与C#良好配合的程序集，因此这样做可以确保我们已经达到了这个目标。
您也可以使用C++/CLI编写NUnit测试并调用非托管的C++代码。可能最好的方法是将您的纯非托管C++代码放在一个库中，然后创建一个使用NUnit并链接到该库的测试程序集。
更简单的方法是，如果您可以接受将未受管控的 C++ 代码仅包含在头文件中，那么它可以被 #include 到测试和最终库或应用程序中。 - Andy Dent
1
我的经验是，使用NUnit无法通过C++/CLI测试C++本地代码，因为您将无法加载和使用本地代码。
我曾尝试使用nunit加载基本的c++/cli测试dll，该dll链接到“just thread”，这是c++标准线程库的实现。 使用最新版本的NUnit（2.6.2），测试dll甚至无法加载。
所以绝对不是可行的方法！
1

它非常有效，并且为您提供参数化测试以及通用测试运行器和框架的好处，如果您处于混合环境中。

有两个缺点，对于大多数情况来说都不严重：

  1. 如果您非常挑剔，那么测试不再在纯本地环境中运行，因此有可能在测试期间正常工作但在运行时失败。我认为您必须做一些相当奇特的事情才会有所影响。

  2. 您依赖于您的C++代码能够被包含到C++/CLI程序中。有时这可能会与头文件发生冲突，并强制您的代码使用UNICODE进行构建。总的来说，这是一件好事，因为它揭示了代码中的垃圾部分（例如Win32调用的Ansi变体的不一致使用）。请记住，只有头文件被包含，因此它可能会显示您将头文件暴露在过高的级别上-您的一些包含应该放在cpp实现文件中。

1
我遇到的另一个缺点是，测试框架经常为了隔离而生成 AppDomains，但本机代码会忽略这种隔离。例如，调用托管代码的原生线程最终会进入默认的 AppDomain。 - Kevin Coulombe
0
1
有几个C++单元测试框架，都非常不错。我只是对在本地代码上使用NUnit的可能性感到好奇。 - Ferruccio
0

最大的问题是C++/CLI语言（以前称为Managed C++）本身的学习曲线，如果测试需要被非C++开发人员理解或维护。

至少需要1-2年的C++ OOP经验才能够为C++CLI/NUnit测试项目做出贡献，并解决托管-本机代码接口之间出现的各种问题。（通过贡献，我指的是能够独立工作并能够创建模拟对象，在C++/CLI中实现和使用本机接口等，以满足所有测试需求。）

有些人可能永远无法掌握足够好的C++/CLI技能来做出贡献。

对于某些具有非常苛刻测试需求的本机软件库，C++/CLI/NUnit是唯一能够满足所有单元测试需求并保持测试代码敏捷性和能够响应变化的组合。我推荐阅读xUnit Test Patterns: Refactoring Test Code这本书来深入了解这个方向。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接