为 C++ 项目编写测试套件的最佳实践/指南是什么?
2 回答
这是一个非常广泛的问题。对于单元测试和测试驱动开发 (TDD), Microsoft提供了一些有用的(如果部分内容有些陈词滥调)指导- 如果不适用,您可以忽略 Visual Studio 特定的建议。
如果您正在寻找有关系统或性能测试的指导,我会澄清您的问题。Boost.Test的文档中有一个不错的更广泛的理由。
在我们结束之前,有几个单元测试最佳实践需要审查。首先,TDD 是一种非常宝贵的实践。在所有可用的开发方法中,TDD 可能是未来许多年最能从根本上改进开发的方法,而且投资很少。任何 QA 工程师都会告诉你,如果没有相应的测试,开发人员就无法编写成功的软件。使用 TDD,实践是在编写实现之前编写这些测试,理想情况下,编写测试以便它们可以作为无人参与的构建脚本的一部分运行。养成这种习惯需要自律,但一旦养成,没有 TDD 方法的编码感觉就像开车不系安全带一样。
对于测试本身,还有一些有助于成功测试的额外原则:
避免在测试之间创建依赖关系,以便测试需要以特定顺序运行。每个测试都应该是自主的。
使用测试初始化代码验证测试清理是否成功执行,如果没有运行,则在执行测试之前重新运行清理。
在编写任何生产代码实现之前编写测试。
为生产代码中的每个类创建一个测试类。这简化了测试组织,并且可以轻松选择放置每个测试的位置。
使用 Visual Studio 生成初始测试项目。这将显着减少手动设置测试项目并将其与生产项目关联时所需的步骤数量。
避免创建其他依赖于机器的测试,例如依赖于特定目录路径的测试。
创建模拟对象来测试接口。模拟对象在测试项目中实现,以验证 API 是否匹配所需的功能。
在继续创建新测试之前验证所有测试是否成功运行。这样,您可以确保在破坏代码后立即修复代码。
最大限度地增加可以在无人值守的情况下运行的测试数量。在完全依赖手动测试之前,请绝对确定没有合理的无人值守测试解决方案。
TDD 无疑是一组最佳实践。在改造测试时,我的目标是代码覆盖率和边界条件覆盖率两件事。基本上,您应该选择函数的输入,以便 A) 如果测试所有代码路径的所有排列,则所有代码路径都经过测试并且更好(有时这可能是大量情况,如果路径差异表面上不同,则实际上没有必要)和B) 如果您的代码中有一个 if x > 5,您使用 x = 5 和 x = 6 测试所有边界条件(这些是导致代码路径选择变化的条件),以得到边界的两侧。