C ++unit testing框架
我为我的C ++代码使用Boosttesting框架，但是有两个问题可能对所有C ++testing框架都是通用的：
- 没有办法创build自动testing存根（例如通过从选定的类中提取公共函数）。
- 你不能运行一个单一的testing – 你必须运行整个“testing套件”（除非你创build了很多不同的testing项目）。
有谁知道更好的testing框架还是我永远嫉妒可用于Java / .NET开发人员的testing工具？
我刚刚回答了一个非常类似的问题 。 我最终使用了Noel Llopis的UnitTest ++。 我比boost :: test更喜欢它，因为它并不坚持用macros来实现testing工具的主程序 – 它可以插入你创build的任何可执行文件。 它确实受到boost :: test的阻碍，因为它需要一个链接库。我使用了CxxTest，它比C ++中的其他任何东西都更接近 – 自动生成testing（尽pipe它需要Perl成为你的构build系统的一部分来做到这一点）。 C ++只是不提供.NET语言和Java所做的reflection钩子。 Visual Studio Team System – Developer's Edition中的MsTest工具将自动生成非托pipeC ++的testing存根，但是这些方法必须从DLL中导出才能执行此操作，因此它不适用于静态库。 .NET世界中的其他testing框架也可能具有这种能力，但我对这些function并不熟悉。 所以现在我们使用UnitTest ++作为非托pipeC ++，而且我正在为托pipe库决定MsTest和NUnit。
我刚把自己的框架CATCH推到了那里。 它仍在开发中，但我相信它已经超越了大多数其他框架。 不同的人有不同的标准，但我试图覆盖大部分地面，没有太多的权衡。 看看我的链接的博客条目品尝师。 我的五大特点是：
- 只有标题
- 自动注册基于function和方法的testing
- 将标准的C ++expression式分解成LHS和RHS（所以你不需要一整套assertmacros）。
- 支持基于function的夹具中的嵌套部分
- 使用自然语言命名testing – 生成函数/方法名称
它不会生成存根 – 但这是一个相当专业的领域。 我认为隔离器++是第一个真正把它解决的工具。 请注意，Mocking / stubbing框架通常独立于unit testing框架。 CATCH对于模拟对象特别有效，因为testing状态不是由上下文传递的。
它也有Objective-C绑定。
[更新]
刚刚几年前，我回到了我的这个答案。 感谢所有伟大的评论！ 很显然，当时Catch已经发展了很多。 它现在支持BDD样式testing（给定/当时），标签，现在在一个单独的头文件中，以及大量的内部改进和改进（例如更丰富的命令行，清晰和富有performance力的输出等）。 更新的博客文章在这里。
看看Google C ++testing框架。
Google使用它的所有内部C ++项目，所以它一定是相当不错的。
http://googletesting.blogspot.com/2008/07/announcing-new-google-c-testing.html
Boost.Test允许按名称运行testing用例。 或testing套件。 或者其中几个。
Boost.Test并不坚持实现main，尽pipe这样做很容易。
Boost.Test不需要用作库。 它有单头变体。
我是UnitTest ++的忠实粉丝，它非常轻便，但是做这个工作。 您可以轻松地在那里运行单个testing。
好问题！ 几年前，我一直在环顾四周，看看有什么值得使用的东西。 我一直在寻找一些非常轻量级的东西，并不需要我链接到一些图书馆…你知道我可以在几分钟内起床和运行的东西。
但是，我坚持并最终跑过了cxxtest 。
从网站：
- 不需要RTTI
- 不需要成员模板function
- 不需要exception处理
- 不需要任何外部库（包括内存pipe理，文件/控制台I / O，graphics库）
- 完全分发为一组头文件（和一个python脚本）。
哇…超级简单！ 包含一个头文件，从Test类派生出来，然后closures并运行。 过去四年来我们一直在使用这个技术，而且我还没有find任何我更满意的东西。
尝试WinUnit 。 这听起来很棒，而且是由John Robbins推荐的。
我喜欢Boostunit testing框架，主要是因为它非常轻便。
-
我从来没有听说过会产生存根的unit testing框架。 我一般都不太相信代码生成，只是因为它很快就被淘汰了。 当你有大量的类时，它可能会变得有用吗？
-
testing驱动开发的支持者可能会说，每次运行整个testing套件是至关重要的，以确保您没有引入回归。 如果运行所有的testing需要花费太多时间，也许你的testing太大了，或者调用CPU密集型函数的时候应该被嘲笑？ 如果它仍然是一个问题，那么在unit testing周围的一个简单的包装应该允许你select你的testing，而且可能比学习另一个框架和移植所有的testing更快。
我正在使用tut框架
Aeryn是另一个值得关注的框架
Visual Studio有一个内置的unit testing框架，这是build立win32控制台应用程序testing项目的一个很好的链接：
http://codeketchup.blogspot.ie/2012/12/unit-test-for-unmanaged-c-in-visual.html
如果你正在处理一个静态DLL项目，那么设置起来就容易多了，因为其他人指出外部testing框架，如GTest和Boost有额外的function。
CppUnit是对JUnit的原始敬意。
Eclipse / JUnit是一个适用于java的可靠包，并且都有C ++扩展/等价物。 它可以做你正在谈论的。 当然，你必须改变IDE …
我也是UnitTest ++的粉丝。
问题是源代码分发包含几乎40个独立的文件。 这是荒谬的。 pipe理一个简单的项目的源代码pipe理和构build任务主要是通过照顾所有这些unit testing文件。
我修改了UnitTest ++，以便通过添加一个.h和.cpp文件来将它与项目集成。 这个我被称为“最可爱”。 详情请见http://ravenspoint.com/blog/index.php?entry=entry080704-063557
它不会像原始问题那样自动生成testing存根。 我不禁认为这样的function比它的价值更麻烦，产生大量无用的代码“testing”访问函数。
我想可以自动地将testing函数存起来，这更多的是一个函数（框架的脚本或者相关的开发环境）。 假设CodeGear的C ++ Builder应用程序将快速生成用户函数的testing代码。
安德鲁马洛的果糖图书馆的价值检查… http://fructose.sourceforge.net/
我记得他的文件中包含了一个相当详细的分析和比较，当他写果糖时，提供的其他产品，但不能find一个URL直接到该文件。
我正在尝试Igloo ，也是一个只有C ++testing套件的头文件，即使是两个包含的依赖项也只是头文件。
所以，这非常简单。 除了github上包含的例子之外，主站点igloo-testing.org上还有例子和更多的细节。 稍后我会更新这个，因为我有更多的经验和其他框架。
