我坚信使用单元测试作为构建大型多平台应用程序的一部分。我们目前计划在一个单独的项目中进行单元测试。这样做的好处是保持我们的代码库干净。然而,我认为这会将测试代码与单元的实现分开。您对这种方法有何看法?是否有适用于 C++ 应用程序的 JUnit 等工具?

有帮助吗?

解决方案

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

无论如何,有一些评估 C++ TU 框架的“论文”:

其他提示

这是一个合理的做法。

我都取得了很好的成绩 单元测试++升压测试

我研究过 CppUnit,但对我来说,它感觉更像是 JUnit 内容的翻译,而不是针对 C++ 的东西。

更新: 这些天我更喜欢使用 抓住. 。我发现它有效且易于使用。

您应该将基本代码分离到共享(动态)库,然后为该库编写单元测试的主要部分。

两年前(2008 年)我参与了 Linux 基金会部署的大型 LSB 基础设施项目。该项目的目标之一是为 Linux 核心库中的 40,000 个函数编写单元测试。在这个项目的背景下,我们创建了 AZOV技术 和名为的基本工具 API 健全性自动测试 为了自动生成所有测试。您可以尝试使用此工具为您的基础库生成单元测试。

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

Cppunit 是 C++ 应用程序中 Junit 的直接等价物http://cppunit.sourceforge.net/cppunit-wiki

就我个人而言,我在不同的项目中创建了单元测试,并创建了一个单独的构建配置来构建所有单元测试和相关源代码。在某些情况下,我想测试类的私有成员函数,因此我将 Test 类设置为要测试的对象的友元类,但在通过预处理器声明构建“非测试”配置时隐藏了友元声明。

然而,当我将测试集成到遗留代码中时,我最终进行了这些编码练习。如果您一开始的目的是进行单元测试,那么更好的设计可能很简单。

您可以在源树中的每个库的子目录中为该库创建一个单元测试项目。您最终会得到每个库的测试驱动程序应用程序,这使得运行一套测试变得更加容易。通过将它们放在子目录中,可以保持代码库干净,同时也使测试保持靠近代码。

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

多年来我一直在使用原始 CppUnit 的定制版本,并取得了巨大成功,但现在还有其他替代方案。 谷歌测试 看起来很有趣。

我认为您在单元测试方面走在正确的道路上,这是提高产品可靠性的一个伟大计划。

尽管单元测试并不能解决将应用程序转换到不同平台甚至不同操作系统时的所有问题。原因是流程单元测试是为了发现应用程序中的错误。它只是简单地将尽可能多的输入放入您的系统中,然后等待另一端的结果。这就像让一只猴子不断地敲击键盘并观察结果(Beta 测试人员)。

要进入下一步,通过良好的单元测试,您需要专注于应用程序的内部设计。我发现的最好方法是使用称为“契约编程”或“契约设计”的设计模式或设计过程。另一本书对于将可靠性构建到核心设计中非常有帮助。

调试开发过程:保持专注、按时交付和建立坚实团队的实用策略。

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

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

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

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

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top