没有单元测试的敏捷

Question

如果您正在处理的代码库有0%的单元测试覆盖率，那么谈论“敏捷开发”或声称您正在应用“敏捷方法”有意义吗？(作为一个团队，你们对此没有采取任何行动)。

要说清楚:对我来说，这是没有意义的。在我个人的经验中，我发现单元测试是唯一允许您真正“敏捷”的工具(即响应更改、改进设计、共享知识等)。TDD是唯一带你去那里的练习。

也许还有其他的方法，但我仍然看不出它们是如何工作的。

Answer 1

要变得迂腐，敏捷宣言或Scrum指南中没有提到任何技术实践，比如单元测试或TDD。因此，是的，从理论上讲，您可以提前交付，并且通常只关注协作和价值，而不需要它们，并称自己为敏捷，您甚至可能实际上具有敏捷性。

然而，在实践中，如果没有一个好的测试套件，几乎不可能每隔几周就将价值(投入到生产中)交付一次。这包括集成测试和单元测试。单元测试只进行到目前为止。这是S金字塔而不是长方形的原因。

如果没有测试作为一个安全网，您将要么在每个版本中引入许多回归错误，要么害怕重构。这两者都将极大地影响你继续以可持续的速度前进的能力。如果你不能保持你的步伐，或者在需要的时候改变方向(重新设计)，那么你就没有敏捷性。毕竟，敏捷性是我们所追求的目标。

Answer 2

敏捷宣言简单地说：

过程和工具上的个人和交互

基于综合文档的工作软件

合同谈判中的客户协作

响应按计划进行的变更

没有提到单元测试。甚至12个项原则也没有提到测试。

因此，从技术上讲，不需要编写单元测试就有可能成为一个敏捷团队。然而，在实践中，很难看出团队如何在没有测试的情况下维护敏捷环境中的工作软件，以帮助他们进行不断的更改。

Answer 3

尽管没有像其他人在这里回答的那样直接描述单元测试或TDD或敏捷宣言中的任何测试，但我相信一个优秀的Scrum或开发人员将能够识别宣言中的一条语句。

工作软件超过全面的文件。

怎么会有人知道这个软件是否工作呢？宣言不需要明确说明测试这一术语。很简洁。

单元测试(在主题的上下文中)将使您的编码阶段在早期阶段缓慢，但随着您的进步，它将是值得的，使开发更快地向前推进。它为您在代码级测试上提供了良好的粒度控制，并使您的设计具有可伸缩性，使您相信您的软件正在工作，并且可以轻松地处理回归；这将使您的开发变得敏捷。