问编写测试套件的指导原则

EN

这是一个非常宽泛的问题。对于单元测试和测试驱动开发(TDD)，有一些关于此from Microsoft的有用(如果部分内容有些陈词滥调)的指导-如果不适用，您可以忽略Visual Studio特定的建议。

如果您正在寻找有关系统或性能测试的指导，我可以澄清您的问题。在docs for Boost.Test中有一个像样的更广泛的理由。

在我们结束之前，有几个单元测试的最佳实践需要回顾。首先，TDD是一种无价的实践。在所有可用的开发方法中，TDD可能是在未来许多年内最根本地改进开发的方法，并且投资最少。任何QA工程师都会告诉你，没有相应的测试，开发人员就不可能写出成功的软件。对于TDD，实践是在编写实现之前编写这些测试，理想情况下，编写测试以便它们可以作为无人参与构建脚本的一部分运行。养成这个习惯需要自律，但是一旦养成了这个习惯，没有TDD方法的编码就像没有安全带的驾驶一样。

对于测试本身，有一些额外的原则将有助于成功的测试：

避免在测试之间创建依赖关系，使测试需要以特定的顺序运行。每个测试都应该是自主的。

使用测试初始化代码验证测试清理是否成功执行，如果未运行，则在执行测试之前重新运行清理。

在编写任何生产代码实现之前编写测试。

为生产代码中的每个类创建一个测试类。这简化了测试组织，并使选择放置每个测试的位置变得很容易。

使用Visual Studio生成初始测试项目。这将大大减少手动设置测试项目并将其与生产项目关联时所需的步骤数量。

避免创建其他依赖于计算机的测试，例如依赖于特定目录路径的测试。

创建模拟对象来测试接口。在测试项目中实现模拟对象，以验证API是否匹配所需的功能。

在继续创建新测试之前，请确认所有测试都已成功运行。这样，您就可以确保在破坏代码时立即修复它。

最大化可以在无人参与的情况下运行的测试数量。在完全依赖手动测试之前，绝对确保没有合理的无人值守测试解决方案。

TDD当然是一套最好的实践。在改进测试时，我的目标是代码覆盖率和边界条件覆盖率。基本上，您应该选择函数的输入，以便A)测试所有代码路径，如果测试所有代码路径的所有排列会更好(有时这可能是大量的情况，如果路径差异表面上不同，则不是真正必要的)和B)如果您的代码中有一个if x> 5，则测试所有边界条件(那些导致代码路径选择变化的条件)，您使用x=5进行测试，x=6得到边界的两边。