【问题标题】:State of the art C++ Unit Testing?最先进的 C++ 单元测试?
【发布时间】:2014-01-03 14:24:12
【问题描述】:

对于 C++ 语言的单元测试,最现代的方法是什么?具有更大自省能力的语言类(如 Python)具有更自然地使用的单元测试框架。单元测试可以更容易地定义。相比之下,经典的CppUnit(基于JUnit)似乎采取了非常保守的方法。有什么更新更好的东西可以利用 C++(甚至 C++11)的特殊功能让生活更轻松吗?

我在 Windows 原生 C++(Visual Studio 2005 和 2010)上以相当简单的方式使用 CppUnit 框架。我们之前没有选择测试驱动开发方法,因为已经有很多遗留代码,我们发现为它添加测试非常困难。我们不得不重构应用程序,但即使在这种情况下,添加所有好的测试也很耗时。

最近,我们已经切换到 Visual Studio 2013(因为 C++11 标准实现),我们将开始新的、相当长期的项目。

之前有良好的(少量)单元测试经验,我想尝试测试驱动开发方法。由于该项目不是一个小项目(预计大小与旧项目大致相同,即大约 200 k 行代码),我更喜欢更简单(但能力不弱)的框架。

新项目有可能导致跨平台实施(Windows 和 Linux)。 Visual Studio 2013 中有单元测试支持,但我没有这方面的经验,也不知道它如何适应跨平台。

到目前为止,我已经找到了list of unit testing frameworks for C++。但是,人们看不出它们在原则上有何不同。我目前有三个候选人(保守选择):

  • Boost -- 可能的候选者; C++ 标准的测试平台;因此它很可能会被广泛接受;可能是最大的用户群。好像比CppUnit更高级。
  • CppUnit -- 我知道,但它编写所有代码并不是一种乐趣。
  • Visual Studio 2013 内置——对我来说是新的,不知何故可以生成骨架。

无论如何,这三个似乎都使用了类似的方法。可能VS2013支持生成代码,但这并不意味着它会导致任何更简单的事情。

有什么全新的方法吗?

【问题讨论】:

  • 这个问题被完全改写了。请考虑重新开放。
  • 多年后,我仍然不同意这是题外话。这个问题被完全改写了。过去,它显然引起了一些关注。标记的答案命名了 Catch 工具,但它还包含关于 lest 的 cmets。这样,答案可以被认为是“告诉我工具”。但是,答案与新的通用方法有关。现在积分够多了,我已经投票支持重开。

标签: c++ visual-studio unit-testing cross-platform


【解决方案1】:

唯一值得考虑的测试框架: Catch

有关该库的介绍,另请参阅 herehere

它易于使用(仅包含一个标头的标头库)、可移植,并且具有迄今为止任何 C++ 单元测试框架中最简单、最简洁的语法。

与其他库不同,您无需记住两打不同的宏或不同类型的断言。

你只需使用 REQUIRE:

int one = 1;
REQUIRE( one == 2 );

通过一些巧妙的运算符重载,将在输出中显示原始表达式和扩展参数值:

test.cc(7): FAILED:
  REQUIRE( one == 2 )
with expansion:
  1 == 43

与此相比,使用 IMO 的所有其他框架都是一件苦差事。

在我发现这个之前,我曾经使用过 Boost.Test,但是设置和使用起来很多麻烦。我们在工作中使用 CppUnit,它似乎被设计为尽可能脆弱和痛苦。

我简单看过VS2013的测试框架,但没有尝试过,看起来还可以,但很像模仿“老兵”。它并没有真正尝试比 CppUnit、Boost.Test 和所有其他 Catch 之前出现的更清洁、更简单或更好。所以我会说不要打扰它。测试应该易于编写(并且易于理解),而 Catch 比我在这方面看到的所有其他框架都领先了光年。

【讨论】:

  • @pepr:“我已经阅读了作者与您和其他人的讨论”——在哪里?什么?听起来令人兴奋,希望能提供链接,谢谢!
  • 我不确定,但它可能在 Google 网上论坛groups.google.com/forum/?fromgroups#!forum/catch-forum@jalf,请您指出更好的地方吗?
  • C++11 - 如果您想要一些非常简单的东西(250 LOC),请查看 lest。它是特定于 C++11 的,并且基于与 Catch 相同的表达式分解技术。还有一个 C++03 端口。
  • @Wallacoloo 享受 ;) 不过还是感谢您的评论;我添加了对跨多个文件和相关示例编写测试的支持。
  • doctest 是我对 Catch 的重新实现,非常注重编译速度 - 查看 FAQ 以了解它们有何不同
【解决方案2】:

我已经使用 Visual Studio 2013 内置测试框架大约 6 周了,我非常喜欢它。集成非常好,很容易上手。如果您正在开发一个仅针对 Windows 的项目,那么我强烈推荐它。

【讨论】:

  • 事实上,它将主要是 Windows 项目。不管怎样,你能猜到以后再转成跨平台会有多难吗?你可以将它与另一个框架进行比较吗?有什么看起来接近 VS 框架的吗?
  • 除非它不起作用。对于 VS 2013 中的我来说,我已经尝试了 2 天来让它与一个 hello-world DLL 一起工作。它给出的只是神秘的:“无法设置测试上下文”错误。
  • 通常我每次看到微软提供的单元测试的东西都会给我留下一个压倒性的印象:他们不知道怎么做这些东西!我说我不是讨厌微软,我一直在使用 Visual Studio,而且我是 10 年的 MVP。但说真的,微软的软件开发文化根植于 1970 年代或 1980 年代的思想和组织结构。 MS 内部有很小的小组在实践 TDD 和一些敏捷的表象,但它根本不在文化 DNA 中,这就是为什么他们的敏捷“解决方案”总是不合时宜的原因。
  • 这里是后期添加的(现在是 2015 年)。我在运行 32 位或 64 位的单元测试时遇到了巨大的麻烦。我对每个都有不同的构建配置,但由于各种原因,很难或不可能选择一个涵盖两者的配置(它是一个或另一个)。它非常不透明,几乎不可能在这方面进行配置。因此,我放弃了它以获得更简单的项目/框架,其中 32/64/C++/CLI 位不会混合在一起。
  • 只是好奇...@Sean:3 年后...您还在使用 Visual Studio 2013 内置测试框架吗?作为“我们说话”,我正在努力解决这个问题。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2016-10-27
  • 1970-01-01
  • 1970-01-01
  • 2012-01-08
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多