测试驱动的开发-谁应该编写测试？

最初，开发人员有责任编写测试，但我注意到，在许多情况下/成熟的开发人员中，这些情况甚至没有提供80％的覆盖率。
我有一个质量保证人员专门为给定项目而不是开发人员编写所有测试的情况如何？
有什么缺点吗？

在测试驱动的开发中，测试必须由开发人员编写。否则，开发人员以外的其他人将推动开发。

因此，一旦您将编写测试的工作交给非开发人员，该人便成为开发人员。

我在TDD中的经验是，编写测试代码通常比编写生产代码难。因此，如果您有能力编写良好的单元测试/集成测试代码，那么他们应该编写使这些测试通过的生产代码。

QA的工作是执行完全不同的测试（即可用性/集成测试）。他们真的不必知道代码中使用的技术。

如果您担心代码覆盖率低，则需要对开发人员进行培训。例如，停止任何新功能的工作，直到代码覆盖率增加为止。某些组织甚至在其存储库上预先提交了一个挂钩，从而不允许检入未发现的代码。

最后但并非最不重要的一点是，在“纯” TTD中，根本不应存在任何未发现的代码（因为您首先编写测试）。但是，在某些情况下（尽管人们对此争论不休），可以接受较低的代码覆盖率。例如，有人认为，为POJO的吸气剂/吸气剂编写测试是浪费时间。

那些案例甚至没有覆盖80％

那可能是一个管理问题。

否则可能无关紧要。

首先，覆盖率在80％和100％之间的差额可能很大，却几乎没有收益。

“覆盖”可以指任何东西。代码行，逻辑路径等。我猜你是指代码行（不是逻辑路径）。

一些逻辑路径已经通过“检查”进行了很好的测试。代码很明显，没有if语句，复杂度非常低，并且可能不需要额外的测试。

测试增加20％并不总是质量提高20％。

第二。这是一个管理问题。如果管理层想要100％的覆盖率，则他们必须建立一个奖励系统来奖励100％的覆盖率，而不是“足以释放” 80％的覆盖率。

添加质量检查人员来编写更多测试不会有多大帮助。

要达到100％的测试覆盖率，需要增加开发人员编写更多测试。

恕我直言，单元测试不是质量检查流程。它更多地是关于加速开发（通过缩短开发人员的反馈循环）。这应该由编写组件（又称单元）的人员来完成，并着重于组件的用法（由另一位开发人员）。

功能测试是质量检查团队可以并且应该执行的质量检查流程。这些可以由开发人员完成，但非开发人员会更好，因为开发人员可能不知道用户使用应用程序的所有方式。

两者都可以以TDD方式完成。

TDD不仅与测试有关，而且与设计有关。仅仅为了通过测试而编写代码通常会导致代码更小且可维护。如果委派任何其他人来编写测试，则还将委派创建良好代码的责任。

您还应该注意，该范围不会告诉您代码质量，也不会告诉您是否涵盖了域规则。

如果您至少需要80％的覆盖率，则需要做几件事：

• 为您的开发人员提供他们所需的工具，以确定他们所拥有的覆盖范围-并确保这是一个成功的过程。衡量覆盖率的方法不止一种。
• 为完成这项壮举提供奖励/激励。程序员只会做他们认为会得到回报的事情。如果50％的覆盖率足以确保质量并完成所有工作，那就是他们将要做的。

最后，了解预期的执行路径与意外的执行路径之间存在差异。在编写测试驱动的代码的过程中，您可能已经证明您需要一对独立的if语句。结果，对潜在的四个执行路径中的两个进行了测试。再添加一个独立的if语句，您就有可能执行8条执行路径（即，它呈指数增长）。

请理解，TDD不一定能预测每条潜在的执行路径，因此可能需要编写许多测试才能完成，但由于不需要测试该路径，因此没有编写测试。简而言之，TDD不能保证覆盖范围，但可以保证至少有一项测试来证明确实存在的代码的原因。