我坚信使用单元测试作为构建大型多平台应用程序的一部分。我们目前正计划在一个单独的项目中进行单元测试。这有利于保持我们的代码库干净。但是，我认为这会将测试代码与单元的实现分开。您如何看待这种方法，是否有任何工具，如用于 c++ 应用程序的 JUnit？
问问题
46832 次
9 回答
23
C++ 有许多测试单元框架。CppUnit 肯定不是我会选择的（至少在其稳定版本 1.x 中，因为它缺乏许多测试，并且需要大量冗余代码行）。到目前为止，我首选的框架是CxxTest，我计划有一天评估Fructose 。
无论如何，有一些评估 C++ TU 框架的“论文”：
- 探索 C++ 单元测试框架 Jungle，作者 Noel Llopis
- Overload Journal #78 中的一篇文章
于 2008-09-18T11:57:34.100 回答
12
这是一个合理的做法。
我使用UnitTest++和Boost.Test都取得了非常好的结果
我看过 CppUnit，但对我来说，它更像是对 JUnit 东西的翻译，而不是针对 C++ 的东西。
更新：这些天我更喜欢使用Catch。我发现它有效且易于使用。
于 2008-09-18T11:15:50.893 回答
3
您应该将基本代码分离到一个共享（动态）库中，然后为该库编写单元测试的主要部分。
两年前（2008 年）我参与了由 Linux 基金会部署的大型 LSB 基础设施项目。该项目的目标之一是为 Linux 核心库中的 40.000 个函数编写单元测试。在这个项目的上下文中，我们创建了AZOV 技术和名为API Sanity Autotest的基本工具，以便自动生成所有测试。您可以尝试使用此工具为您的基础库生成单元测试。
于 2011-01-25T15:50:48.803 回答
2
我认为您在单元测试方面走在正确的道路上，这是提高产品可靠性的好计划。
尽管在将您的应用程序转换为不同的平台甚至不同的操作系统时，单元测试并不能解决您的所有问题。这样做的原因是，通过单元测试来发现应用程序中的错误。它只是简单地将尽可能多的输入输入到您的系统中，然后在另一端等待结果。这就像让猴子不断敲击键盘并观察结果（Beta 测试人员）。
要进入下一步，通过良好的单元测试，您需要专注于应用程序的内部设计。我发现最好的方法是使用一种称为“合同编程”或“合同设计”的设计模式或设计过程。另一本书对在您的核心设计中建立可靠性非常有帮助。
调试开发过程：保持专注、按时发货和建立稳固团队的实用策略。
在我们的开发团队中，我们非常仔细地研究了我们认为是程序员错误、开发人员错误、设计错误以及我们如何使用单元测试以及如何通过 DBC 在我们的软件包中构建可靠性并遵循调试开发的建议过程。
于 2008-09-18T11:41:26.167 回答
2
我使用 UnitTest++。测试在一个单独的项目中，但实际测试与实际代码交织在一起。它们存在于被测部分下的文件夹中。即：
MyProject\src\ <- 实际应用程序的源
MyProject\src\tests <- 测试的源
如果您有嵌套文件夹（并且没有），那么它们也将拥有自己的 \tests 子目录。
于 2008-09-18T12:08:37.443 回答
1
Cppunit 是用于 C++ 应用程序的 Junit 的直接等价物 http://cppunit.sourceforge.net/cppunit-wiki
就个人而言，我在不同的项目中创建了单元测试，并创建了一个单独的构建配置来构建所有单元测试和相关的源代码。在某些情况下，我想测试一个类的私有成员函数，因此我将 Test 类作为要测试的对象的友元类，但在通过预处理器声明构建“非测试”配置时隐藏了友元声明。
然而，当我将测试集成到遗留代码中时，我最终完成了这些编码体操。如果您从单元测试的目的开始，更好的设计可能很简单。
于 2008-09-18T11:19:48.513 回答
1
您可以在该库的子目录中为源代码树中的每个库创建一个单元测试项目。您最终会为每个库提供一个测试驱动程序应用程序，这样可以更轻松地运行一套测试。通过将它们放在子目录中，它可以使您的代码库保持干净，但也可以使测试接近代码。
可以轻松编写脚本来运行源代码树中的所有测试套件并收集结果。
多年来，我一直在使用原始 CppUnit 的定制版本并取得了巨大成功，但现在还有其他替代方案。 GoogleTest看起来很有趣。
于 2008-09-18T11:36:55.133 回答
1
使用 tut http://tut-framework.sourceforge.net/ 很简单，只是头文件而已，没有宏。可以生成 XML 结果
于 2008-09-18T12:48:04.120 回答