您如何在大型 C++ 项目中实施单元测试？

How do you implement unit-testing in large scale C++ projects?

提问by Charles Beattie

I believe strongly in using unit-tests as part of building large multi-platform applications. We currently are planning on having our unit-tests within a separate project. This has the benefit of keeping our code base clean. I think, however, that this would separate the test code from the implementation of the unit. What do you think of this approach and are there any tools like JUnit for c++ applications?

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

采纳答案by Luc Hermitte

There are many Test Unit frameforks for C++. CppUnit is certainly not the one I would choose (at least in its stable version 1.x, as it lacks many tests, and requires a lot of redundant lines of codes). So far, my preferred framework is CxxTest, and I plan on evaluating Fructosesome day.

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

Any way, there are a few "papers" that evaluate C++ TU frameworks :

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

• Exploring the C++ Unit Testing Framework Jungle, By Noel Llopis
• an article in Overload Journal #78

• 探索 C++ 单元测试框架丛林，作者：Noel Llopis
• Overload Journal #78 上的一篇文章

回答by Ferruccio

That's a reasonable approach.

这是一个合理的做法。

I've had very good results both with UnitTest++and Boost.Test

我在UnitTest++和Boost.Test 上都有很好的结果

I've looked at CppUnit, but to me, it felt more like a translation of the JUnit stuff than something aimed at C++.

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

Update:These days I prefer using Catch. I found it to be effective and simple to use.

更新：这些天我更喜欢使用Catch。我发现它有效且易于使用。

回答by linuxbuild

You should separate your base code to a shared (dynamic) library and then write the major part of your unit tests for this library.

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

Two years ago (2008) I have been involved in large LSB Infrastructure project deployed by The Linux Foundation. One of the aims of this project was to write unit tests for 40.000 functions from the Linux core libraries. In the context of this project we have created the AZOV technologyand the basic tool named API Sanity Autotestin order to automatically generate all the tests. You may try to use this tool to generate unit tests for your base library (ies).

两年前（2008 年），我参与了 Linux 基金会部署的大型 LSB 基础设施项目。该项目的目标之一是为 Linux 核心库中的 40.000 个函数编写单元测试。在这个项目的上下文中，我们创建了AZOV 技术和名为API Sanity Autotest的基本工具，以便自动生成所有测试。您可以尝试使用此工具为您的基本库生成单元测试。

回答by graham.reeds

I use UnitTest++. The tests are in a separate project but the actual tests are intertwined with the actual code. They exist in a folder under the section under test. ie:
MyProject\src\ <- source of the actual app
MyProject\src\tests <- the source of the tests
If you have nested folders (and who doesn't) then they too will have their own \tests subdirectory.

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

回答by Chad

I think your on the right path with unit testing and its a great plan to improve reliability of your product.

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

Though unit testing is not going to solve all your problems when converting your application to different platforms or even different operating systems. The reason for this, is the process unit testings goes through to uncover bugs in your application. It just simply throws as many inputs imaginable into your system and waits for a result on the other end. Its like getting a monkey to constantly pound at the keyboard and observing the results(Beta testers).

尽管在将应用程序转换到不同平台甚至不同操作系统时，单元测试并不能解决所有问题。这样做的原因是过程单元测试通过以发现应用程序中的错误。它只是简单地将尽可能多的输入投入您的系统，并在另一端等待结果。这就像让一只猴子不断敲击键盘并观察结果（Beta 测试人员）。

To take it to the next step, with good unit testing you need to focus on your internal design of your application. The best approach i found was to use a design pattern or design process called "contract programming" or "Design by contract". The other book that is very helpful for building reliability into your core design was.

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

Debugging the Development Process: Practical Strategies for Staying Focused, Hitting Ship Dates, and Building Solid Teams.

调试开发过程：保持专注、按时交货和建立稳固团队的实用策略。

In our development team, we looked very closely at what we consider to be a programmer error, developer error, design error and how we could use both unit testing and also building reliability into our software package through DBC and following the advice of debugging the development proccess.

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

回答by David Sykes

CxxTestis also worth a look for lightweight, easy to use cross platform JUnit/CppUnit/xUnit-like framework for C++. We find it very straightforward to add and develop tests

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

Aerynis another C++ Testing Framework worth looking at

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

回答by David Sykes

Using tut http://tut-framework.sourceforge.net/very simple, just header file only no macros. Can generate XML results

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

回答by NotJarvis

Cppunit is a direct equivalent of Junit for C++ applications http://cppunit.sourceforge.net/cppunit-wiki

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

Personally, I created the unit tests in a different project, and created a separate build configuration which built all the unit tests and dependent source code. In some cases I wanted to test private member functionss of a class so I made the Test class a friend class to the object to be tested, but hid the friend declarations when building in "non-test" configurations through preprocessor declarations.

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

I ended up doing these coding gymnastics as I was integrating tests into legacy code however. If you are starting out with the purpose of unit testing a better design may be simple.

然而，当我将测试集成到遗留代码中时，我最终做了这些编码体操。如果您以单元测试的目的开始，更好的设计可能很简单。

回答by Aaron Hinni

You can create a unit test project for each library in your source tree in a subdirectory of that library. You end up with a test driver application for each library, which makes it easier to run a single suite of tests. By putting them in a subdirectory, it keeps your code base clean, but also keeps the tests close to the code.

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

Scripts can easily be written to run all of the test suites in your source tree and collect the results.

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

I've been using a customized version of the original CppUnit for years with great success, but there are other alternatives now. GoogleTestlooks interesting.

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