c++ - 另一个单元测试/代码覆盖问题。我的方法明智吗？

Question

这是另一个单元测试问题。我正尝试从许多地方吸取有关如何进行的知识，并且我想从这里的专家集合中反射(reflect)出我目前的理解。

假设一个项目，除了 opengl funkiness 之外的所有依赖项都是静态链接的(c 运行时除外)

我目前的理解:

1. 只测试类的公共(public)接口(interface)的单元测试是可以的，因为最终类是最适合测试的单元。可以从那里(在有问题的类内部)找出问题，一个太复杂而无法调试的类，需要对其内部结构进行单元测试，是分解它的一个很好的候选者。从 Visual Studio 的角度来看，这种做法使得在自己的项目中编写单元测试成为可能。

2. 代码覆盖率工具(如 CoverageMeter)安装在主项目中，并提供其自己的构建配置，如测试而不是调试。这会将指标放在目标代码中，供外部“查看器”工具获取指标。

3. 同时，主应用程序在测试配置中构建为库，以便外部单元测试项目使用目标代码来运行其测试。同时，CoverageMeter 代码包含在单元测试项目运行所用的库中，使覆盖率指标衡量在单元测试中执行了多少代码。

4. 通过将测试配置与发布或调试分开，可以使用占位符库来打破依赖关系，例如 opengl。

我的问题确实是:这是天上掉馅饼的东西吗？我的理解对吗？我真的可以做 3 的第一句话吗，我将如何获取单元测试代码以运行主应用程序项目中的目标代码构建，还是有其他方法？

我疯了吗？我对任何批评持开放态度。提前感谢您的宝贵时间。

更新:看起来我对在单元测试中练习什么有正确的想法，但我担心 3. 我对这些组件的理解是否正确？

感谢您的回复。能得到反馈真好!这将是我的第一个大项目，我正在尝试了解所有相关的部分。感谢指点!

乔希

Answer 1

我测试了除私有(private)方法之外的所有方法，因为可以从类外部调用任何其他方法，这有助于确保如果其他人调用我的函数不会给他们带来问题。

如果他们也在测试调用我的代码，那么如果他们做出错误的假设，我们可以很快知道最近的更改破坏了某些东西。

更新:我会通过分发和内部测试的其余部分来分发公共(public)功能的任何测试。如果人们要针对我的 API 进行编写，那么单元测试可以作为一个很好的文档来源，以显示我期望发生什么，以及我期望如何处理无效参数。