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