<分区>
我在一个大约有 120 名开发人员的开发团队中工作，其中还有较小的部门。我们的流程介于瀑布和敏捷之间，更倾向于前者。我们没有让我们的构建执行单元测试，并且在各个团队中只是随意使用它们。这里不会发生任何类似 TDD 的事情。
我们一直在进行 Scrum 培训，并正在尝试将敏捷方法用于某些项目，并在未来将其他项目转向敏捷。
很长一段时间以来，我一直担心我们不再强调自动化单元测试。在这个 Scrum/Agile 培训过程中，我试图指出在我们的构建中缺乏自动化单元测试可能是一个问题，对于敏捷过程更是如此，特别是使用短迭代。 “插入者和插入者”对此的回应是，这是一个 XP 主题，我们正在实现 Scrum。
假设您同意我的担忧，我可以向支付账单的人提出什么论点，即开发良好的自动化单元测试基础架构(和理解)需要更高的优先级？
最佳答案
我见过的最好的论据是尽早修复错误成本更低。
特别是，正如您所说，未经测试的短迭代代码在部署时几乎肯定会失败。让团队停下来执行手动测试，然后修复，将不确定性引入日程安排，而理想情况下，Scrum 的最佳实践是明确定义的频繁高质量发布节奏是需要的。
在更大的团队中集成未经测试的代码也很困难:即使是最好的书面规范也可能含糊不清，而且往往更糟。拥有一个良好的健壮测试套件是代码实际功能的一个很好的规范。
代码编写完成后，适当的测试覆盖率让您可以获取代码并在知道它仍按定义工作的情况下对其进行更改。特别是大大减少了与回归测试相关的工作。
我曾看到管理层试图以这种方式“偷工减料”，建议在核心开发职能之外并远离冲刺周期进行测试。根据我的经验，与尽早发现并修复错误相比，软件交付的时间要晚一些。
也许这是一个文化问题，但在英国，我看到的 Scrum 等最佳实践是不要太在意流程的特定部分是 XP、敏捷、Scrum 还是你拥有的东西.相反，检查和适应的策略表明团队可以自己决定通过采用特定策略来改进他们的代码；然后，如果在出现高峰后它似乎起作用，则该政策将被更广泛地采用。或不。
因此，您可能会发现最好等待时机，然后在下次回顾时建议改进测试覆盖率。或者，也许只是自己实现它们……然后观察您的速度提高!
关于unit-testing - 不强调自动化单元测试的开发过程会因 Scrum 而变得更糟吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/8620480/