无需单元测试即可敏捷

如果您正在使用的代码库的单元测试覆盖率为0％，那么谈论“敏捷开发”或声称您正在应用“敏捷方法论”是否有意义？（而且，作为一个团队，您对此没有做任何事情）。

明确一点：对我来说，这没有任何意义。根据我的个人经验，我发现单元测试是使您真正“敏捷”（即响应更改，改进设计，共享知识等）的唯一工具，而TDD是使您达到目标的唯一实践。 。

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

出于学问的考虑，《敏捷宣言》或《 Scrum指南》中没有任何内容引用任何技术实践，例如单元测试或TDD。因此，是的，从理论上讲，您可以及早交付，并且通常将重点放在协作和价值上，而没有它们，并称自己为敏捷，您甚至可能实际上具有敏捷性。

但是实际上，如果没有良好的测试套件，几乎每隔几周就无法持续交付价值（投入生产）。这包括集成测试和单元测试。单元测试仅此而已。毕竟是金字塔而不是矩形的原因。

没有测试作为安全网，您将在每个发行版中引入很多回归错误，或者对重构感到恐惧。两者都会极大地影响您以可持续的速度继续前进的能力。如果您在需要时无法保持步伐或改变路线（重新设计），那么您就没有敏捷性。毕竟，敏捷是我们追求的目标。

敏捷宣言简单地指出：

个人与流程和工具之间的互动

工作软件超过全面的文档

客户合作而非合同谈判

响应计划变更

这里没有提及单元测试。甚至12条原则也没有提到测试。

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

即使没有像其他人在这里回答的那样直接说出单元测试或TDD或敏捷宣言中的任何类型的测试，我相信一个好的Scrum Master或Developer能够辨别宣言中的其中一项陈述。

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

谁会知道该软件是否正常运行？声明无需明确说明测试一词。这是简洁的。

单元测试（在本主题中）将使您的编码阶段在早期阶段变慢，但是随着您的进步，它是值得的，从而使开发速度大大加快。它为您提供了对代码级测试的精细控制，并使您的设计具有可扩展性，使您确信您的软件正在运行并且可以轻松处理回归。使您的开发敏捷。

绝对有道理。敏捷不是像其他人已经提到的那样进行测试，而是要专门回答您的问题：

不，您根本不需要单元测试。

您只能通过集成测试来运行敏捷过程。例如，您可以每晚进行一次自动集成测试，并修复第二天发现的错误。如果愿意，可以让一个手动测试器连续运行集成测试。无论使用哪种系统，单元测试都是完全可选的。

您可能会发现单元测试可以帮助您进行开发，并且相当公平，但是很多事情可以帮助您进行开发，而您可能没有。

尽管您确实是旧的“客户Beta测试人员”，但您仍需要某种形式的测试。如果您的客户大量参与该过程，并且不介意查找错误，那么它可以起作用-因为他们倾向于查找甚至没人认为是错误的错误！

不是必需的 当您有真正知道如何使用它的人时，测试就很棒。如果您不这样做，那么不仅没有必要，而且这也成为一种责任。我想说有很多程序员不是很熟练。

我很高兴您在您的问题中承认敏捷是您实际发布软件的方式，而不是遵循某些方法。敏捷宣言是一个很好的参考，但它不是权威指南。敏捷比它先存在。有多种方法可以使软件开发更加“敏捷”，但是可以在各种项目中使用不同的组合。

如果您以客户可以接受的速度发布新软件，则可能很敏捷。我也将包括不要过多推后推，并抱怨开发人员对功能的更改。只解决一件事而打破另一件事也不理想。当用户的升级版本落后几个版本时，无论是否进行测试，您可能都不太灵活。

我想反驳（其他答案）争论，敏捷宣言确实明确指出了这一点，即：

持续关注技术卓越 和良好的设计可提高敏捷性。

我真的很喜欢LeSS对技术卓越性的定义，它包括单元测试和TDD。现在您可以争辩说，您可能不需要单元测试和TDD来实现这一目标，但这是最常见的建议方法。

组织敏捷性受技术敏捷性的约束

换句话说，当您对产品进行更改的速度很慢时，无论您如何构建团队，组织或采用哪种框架都没有关系，您对更改的响应就会很慢。

如果您可以防止产品以其他方式抵抗变化，那么您可能会走上正确的路，但是：

我发明了极限编程，以确保程序员的安全。–肯特·贝克

Scrum缺乏任何技术实践，但是Jeff对此发表了以下看法：

我从未见过没有使用极限编程开发实践的高效率Scrum团队。–杰夫·萨瑟兰

从本文引用：http : //ronjeffries.com/articles/017-02ff/gathering2017/

我希望没有技术实践的Scrum团队最终会通过回顾来得出类似的实践。您也想变得高产吗？

在敏捷通量模型，提到它在这两个明星级别：

有用的技术包括持续集成，测试驱动的开发，结对编程和集体所有权。

如果您仅将敏捷流利性的目标定为第一级，则可以跳过该实践，但是任何更大，运行时间更长的产品都应至少尝试达到两星级的水平。

因此，普遍的共识是，是的，如果没有良好的单元测试，清晰的代码和重构实践，那么当前不可能真正实现敏捷。随着新技术实践的出现，这种情况将来可能会改变。

如果我们问一些宣言的签字人，例如罗伯特·C·马丁，马丁·福勒或肯特·贝克，您会如何回答？也许他们会说这取决于情况，但是通常这是您应该做的事情。