我坚信将单元测试用作构建大型多平台应用程序的一部分。目前，我们正在计划在一个单独的项目中进行单元测试。这具有保持我们的代码库干净的好处。但是，我认为这会将测试代码与单元的实现分开。我们如何看待这种方法，是否有诸如JUnit这样的工具可用于c ++应用程序？

解决方案

这是一个合理的方法。

我在UnitTest ++和Boost.Test上都取得了很好的结果

我看过CppUnit，但对我来说，它更像是JUnit的翻译，而不是针对C ++的。

更新：最近，我更喜欢使用Catch。我发现它是有效且易于使用的。

Cppunit是Junit对于C ++应用程序的直接等效项
http://cppunit.sourceforge.net/cppunit-wiki

我个人在另一个项目中创建了单元测试，并创建了一个单独的构建配置，该配置构建了所有单元测试和相关的源代码。在某些情况下，我想测试一个类的私有成员函数，因此我将Test类作为要测试对象的朋友类，但是在通过预处理器声明构建"非测试"配置时隐藏了朋友声明。

但是，当我将测试集成到旧代码中时，我最终完成了这些编码体操。如果我们出于单元测试的目的而开始，那么更好的设计可能会很简单。

我们可以在源树中该库的子目录中的每个库中创建一个单元测试项目。我们最终为每个库提供了一个测试驱动程序应用程序，这使得运行单个测试套件变得更加容易。通过将它们放在子目录中，可以使代码库保持整洁，还可以使测试与代码接近。

可以轻松编写脚本以运行源代码树中的所有测试套件并收集结果。

多年来，我一直在使用原始CppUnit的自定义版本，取得了巨大的成功，但是现在还有其他选择。 GoogleTest看起来很有趣。

我认为我们可以通过单元测试走上正确的道路，它是提高产品可靠性的绝佳计划。

尽管将应用程序转换到不同的平台甚至不同的操作系统时，单元测试并不能解决所有问题。这样做的原因是，过程单元测试需要进行检查才能发现应用程序中的错误。它只是简单地将尽可能多的输入抛出到系统中，并在另一端等待结果。就像让猴子不断敲打键盘并观察结果(测试版)一样。

为了进行下一步，通过良好的单元测试，我们需要专注于应用程序的内部设计。我发现的最佳方法是使用称为"合同编程"或者"按合同设计"的设计模式或者设计过程。另一本对在核心设计中建立可靠性非常有帮助的书是。

调试开发过程：保持专注，达成发运日期和建立扎实团队的实用策略。

在我们的开发团队中，我们非常仔细地研究了我们认为是程序员错误，开发人员错误，设计错误以及如何使用单元测试以及如何通过DBC并在软件包中建立可靠性以及遵循调试开发的建议处理。

CxxTest还值得一看的是，C ++的轻量级，易于使用的跨平台JUnit / CppUnit / xUnit类框架。我们发现添加和开发测试非常简单

Aeryn是另一个值得关注的C ++测试框架

有许多用于C ++的测试单元框架。
CppUnit当然不是我会选择的(至少在其稳定版本1.x中，因为它缺乏许多测试，并且需要大量的冗余代码行)。
到目前为止，我首选的框架是CxxTest，我计划在某天评估果糖。

无论如何，有一些评估C ++ TU框架的"论文"：

• 探索C ++单元测试框架丛林，作者Noel Llopis
• 过载日志＃78中的一篇文章

我使用UnitTest ++。测试在一个单独的项目中，但实际测试与实际代码交织在一起。它们存在于被测部分下的文件夹中。
IE：
MyProject \ src \ <实际应用程序的源
MyProject \ src \ tests <测试源
如果我们有嵌套文件夹(没有嵌套文件夹)，那么它们也将有自己的\ tests子目录。

使用tut http://tut-framework.sourceforge.net/
很简单，只是头文件而已，没有宏。可以生成XML结果