为每个新错误添加一个单元测试

在我的工作中，所有解决错误的开发人员都必须添加一个新的单元测试，以警告此类错误（如果再次出现这种情况）。如果无法进行单元测试（例如，网页设计问题），则质量检查部门必须创建一个测试用例以手动检查它。

其背后的想法是，如果在产品发布之前未检测到缺陷，是因为没有适当的单元测试来检测它。因此，开发人员必须添加它。

问题是：这在任何软件开发方法中都常见吗？这个技术有名字吗？我想了解更多有关它的信息，但是我需要一些信息来开始它。

这很普遍。我们在团队中使用它。对于每个生产缺陷，开发人员必须在问题的根本原因上添加注释，添加失败的单元测试并添加测试影响分析，然后才能将故障单推入开发人员状态以检入代码。

必须通过失败的单元测试，然后才能将代码推送到生产环境。

除了一般的“回归测试”外，我没有其他名称。这非常有用，在开始执行此过程之后，我们开始看到产品质量的提高。

绝对！

如果您可以同意单元测试是件好事，那么您将意识到，如果存在错误，那么缺少覆盖该代码路径的单元测试。

因此应该发生的事情是，编写一个表明该错误存在的单元测试，修复实际的错误，然后该单元测试将通过。

如果根本没有单元测试，那么这可能是开始将单元测试引入项目的一种好方法。

该技术是测试驱动的开发。尽管可重复测试套件总是很有帮助，但这并不是真的能够下次发现类似的错误。关键是，您可以证明您已隔离了代码中的错误，证明了错误，对其进行了修复，证明该修复是正确的。

有一个引用我不太记得或找不到，但大概是：“每个错误都是尚未编写的测试。”

恕我直言，试图将其作为回归测试出售是一场失败的战斗。考虑到这些事情很少会遇到重复的错误，大多数开发人员只会说：“为什么不打扰我什么时候可以简单地解决它？”

这项技术相当普遍，我认为最好的名称是“ Defect Driven Testing”（我自己想到了它，然后很久以前发现它是以该名称描述的）。

有时您可能会看到有人将这些测试称为“回归测试”，但是我个人觉得很难为这个名字辩护。“回归测试”的一种更广泛的定义（可以用这个名字来称呼它更有意义）是“在对代码进行任何更改之后运行测试，以确保您没有引入任何回归”和CI在推送到存储库时测试每个分支是否满足要求。