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