c++ - 使用 C/C++ 进行单元测试：经验教训，要记住什么？

Question

使用 C/C++ 进行单元测试：你教那些以前没有做过单元测试或者来自 Java/Junit 的人什么？

从您的角度来看，最重要的课程/要记住/练习的事情是什么，可以节省大量时间或压力（尤其是关于 C/C++）？

Answer 1

1. 单元测试必须在每次签入时自动运行（或者，编写然后忘记的单元测试不是单元测试）。
2. 在修复错误之前，编写一个单元测试来公开它（它应该会失败）。然后修复错误并在测试变为绿色时欢欣鼓舞。
3. 为了更容易测试而牺牲一个类的一些“美”是可以的（比如提供不应该真正公开的公共方法，但有助于您的测试/模拟）。

Answer 2

读这个......无论如何你都会......

Answer 3

我反对所有这些自动授予测试类友谊的建议......

就我个人而言，我更喜欢关注以下内容，以允许我访问我需要测试的类的内部：

1. 尽可能依赖类的公共接口；有时这意味着稍微扩展公共接口以便于测试。不要过多地与这些扩展作斗争，但也不要让它们过多地驱动你的设计......
2. 考虑添加一个可供“真实”代码和测试代码使用的监控接口，以启用对被测代码的监控。（我仍然惊讶于这是设计过程中非常好的一部分）。
3. 考虑通过“受保护的接口”向派生类提供对类的某些部分的访问，并派生相关类的“可测试”版本，然后可以对其进行检测和测试。

总而言之，我更喜欢看到在测试点中设计，而不是与测试类建立全面的友谊。当然，前者比后者更难做，但恕我直言，会产生更好的代码和更好的测试。

Answer 4

我想改写 ripper234 并添加更多规则：

1. 每个模块（通常是 DLL 项目）都应该有单独的 UT 项目。所有 UT 类都应该是它们需要从中访问私有方法/成员的所有 DLL 类的朋友。
2. 如果你想改变模块 - 首先改变 UT。在签入前确保 DLL 及其 UT 编译、链接和 UT 运行时没有崩溃和故障。每次签入之前无需为所有模块运行所有 UT - 这是浪费时间。
3. 所有 UT 应与所有 DLL 一起在夜间构建中自动重建。所有 UT 和模块都应该在构建期间编译和链接。
4. 夜间构建成功后应自动运行所有 UT，并汇总结果。
5. 应将包含所有 UT 结果的摘要发布给开发人员，如果出现任何故障或崩溃，应尽快予以纠正。

Answer 5

在处理没有测试的遗留代码库的情况下，您很可能会开始（正如我必须这样做的）使用单元测试框架进行实现的功能测试。不要惊慌——您的代码是如此相互关联，以至于可能无法编写适当的单元测试。也不要自满——一旦功能测试到位，您需要重构以便真正的单元测试成为可能。你的代码会更好！

Answer 6

最重要的一课：有考试总比没有考试好。

Answer 7

一个单元测试用例应该只测试一件事。

与 C# 和 Java 相比，我在 C/C++ 中更经常看到单元测试用例测试整个工作流程。

可能是因为大多数 C/C++ xUnit 框架需要几个步骤来注册一个测试用例，所以在添加新功能时只向现有测试用例添加几行的诱惑更高。