How do you implement unit-testing in large scale C++ projects?我坚信将单元测试用作构建大型多平台应用程序的一部分。 我们目前正在计划在一个单独的项目中进行单元测试。 这样的好处是可以保持我们的代码库干净。 但是，我认为这会将测试代码与单元的实现分开。 您如何看待这种方法，是否有用于C ++应用程序的工具如JUnit？
C ++有许多测试单元框架。 无论如何，都有一些评估C ++ TU框架的"论文"：
这是一个合理的方法。 我在UnitTest ++和Boost.Test上都取得了很好的结果 我看过CppUnit，但对我来说，它更像是JUnit内容的翻译，而不是针对C ++的东西。 更新：最近，我更喜欢使用Catch。我发现它是有效且易于使用的。 您应该将基本代码分离到一个共享的(动态)库中，然后为该库编写单元测试的主要部分。 两年前(2008年)，我参与了Linux基金会部署的大型LSB基础架构项目。该项目的目标之一是为Linux核心库中的40.000个功能编写单元测试。在此项目的上下文中，我们创建了AZOV技术和名为API Sanity Autotest的基本工具，以便自动生成所有测试。您可以尝试使用此工具为基础库生成单元测试。
我使用UnitTest ++。测试在一个单独的项目中，但实际测试与实际代码交织在一起。它们存在于被测部分下的文件夹中。
使用tut http://tut-framework.sourceforge.net/ CxxTest也值得一看，它是针对C ++的轻量级，易于使用的跨平台JUnit / CppUnit / xUnit框架。我们发现添加和开发测试非常简单 Aeryn是另一个值得关注的C ++测试框架 我认为您可以通过单元测试走上正确的道路，它是提高产品可靠性的绝佳计划。 尽管将应用程序转换到不同的平台甚至不同的操作系统时，单元测试并不能解决所有问题。这样做的原因是，过程单元测试需要进行检查才能发现应用程序中的错误。它只是简单地将尽可能多的输入抛出到您的系统中，并在另一端等待结果。就像让猴子不断敲打键盘并观察结果(测试版)一样。 为了进行下一步，通过良好的单元测试，您需要专注于应用程序的内部设计。我发现最好的方法是使用称为"合同编程"或"按合同设计"的设计模式或设计过程。另一本对在您的核心设计中建立可靠性非常有帮助的书是。 调试开发过程：保持专注，达成发运日期和建立坚实团队的实用策略。 在我们的开发团队中，我们非常仔细地研究了我们认为是程序员错误，开发人员错误，设计错误以及如何使用单元测试以及如何通过DBC并在软件包中建立可靠性以及遵循调试开发的建议， proccess。 您可以在源树中该库的子目录中的每个库中创建一个单元测试项目。您最终为每个库提供了一个测试驱动程序应用程序，这使得运行单个测试套件变得更加容易。通过将它们放在子目录中，可以使您的代码库保持整洁，还可以使测试与代码接近。 可以轻松编写脚本以运行源代码树中的所有测试套件并收集结果。 多年来，我一直在使用原始CppUnit的自定义版本，取得了巨大的成功，但是现在还有其他选择。 GoogleTest看起来很有趣。
Cppunit是Junit对于C ++应用程序的直接等效项 我个人在另一个项目中创建了单元测试，并创建了一个单独的构建配置，该配置构建了所有单元测试和相关的源代码。在某些情况下，我想测试一个类的私有成员函数，因此我将Test类作为要测试对象的朋友类，但是在通过预处理器声明构建"非测试"配置时隐藏了朋友声明。 但是，当我将测试集成到旧代码中时，我最终完成了这些编码体操。如果您出于单元测试的目的而开始，那么更好的设计可能会很简单。 |
