如果您不进行TDD（测试驱动开发），是否可以正确地称呼自己（或您的团队）“敏捷”？

是的，是的，是的，是一百万次。

敏捷是一种哲学，TDD是一种特定的方法。

如果我真的想挑剔，我可以简单地指出xDD有很多变体-他们的倡导者将深入解释这些变体不是 TDD-但它们仍然首先与测试密切相关，以致于作弊。

因此，可以这样说-您无需执行“测试优先”开发即可变得敏捷（看看scrum的工作方式-没有关于编写代码的细节的地方）。看一个看板，看各种各样的敏捷方法。

您要单元测试吗？当然，出于各种原因，您会这样做-您可能会提出一个论点，即没有单元测试就无法敏捷（尽管我怀疑您可以做到）-但您不必先编写它们就可以敏捷。

最后，同样的事实是，无论您的总体开发理念如何，都可以在不敏捷的情况下进行“ 测试优先” ，并且坚决主张进行测试。

似乎其他人（具有更多SOLID代表）也有类似的看法...

http://www.twitter.com/unclebobmartin/status/208621409663070208

@unclebobmartin：http ://t.co/huxAP5cS 尽管没有TDD和OOD并非不可能做到敏捷，但这很困难。没有TDD的迭代率...

（推文中的链接是LinkedIn上的完整答案）

“敏捷”只是意味着遵守敏捷宣言的价值观和原则。该文档中没有任何内容提及TDD，甚至没有提及单元测试。

因此，是的，您无需进行TDD或单元测试即可变得敏捷。

我不推荐它...

是的，

查看敏捷值之一：

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

那应该已经回答了。TDD是某种方法论，是一个过程。确实，可以在敏捷开发过程中使用的过程，仅此而已。我认为，当敏捷时，TDD可能是最新技术。但是我认为，即使TDD已被其他实践所取代，敏捷的概念仍将持续下去。

我将其总结为：

• 今天，TDD已成为敏捷的事实上的标准

• 没有TDD可能会有敏捷的方法

我说

没有[某种]

如果您返回原始来源，http：//en.wikipedia.org/wiki/Extreme_Programming TDD对于该过程至关重要。这些测试代替了瀑布的需求规格和用例，充当了活动文档和功能示例等。它们是必不可少的。

但是，现在有太多不同的“敏捷”风格浮出水面，其中之一完全有可能避开TDD

编辑：@Murph对问题的解释似乎是首选的解释。哎呀，我什至赞成，这是一个很好的答案。但是，我坚持我的观点，即敏捷宣言是一套原则，而不是一种开发方法。在没有实际实施带来好处的实践的情况下，说“噢，我很敏捷”是没有用的。尤其是：

工作软件是进度的主要衡量标准。

和

敏捷过程促进可持续发展。赞助商，开发商和用户应能够无限期地保持恒定的步伐。

对我来说，这两个原则意味着甚至不需要TDD －至少我知道，没有它，没有其他方法可以实现它们！

编辑2：是的，从技术上讲，您可以在以后编写测试；但我仍然将测试优先/ TDD视为根本。不是因为没有它就不能“敏捷”，而是因为您会更加敏捷。测试优先/测试驱动比事后测试/事后测试要有效得多。测试说明是要求。不要把它们推迟到以后;-)

编辑3：我终于想出了什么让我对Murph的写得很好的答案感到如此困扰。正是这种观念认为，如果不实际进行操作，人们可能会“变得敏捷” 。而“这样做”（如上所示）几乎需要TDD。

严格来说，您遵循敏捷宣言就是敏捷的。在实践中，除非具有良好的测试覆盖范围，否则代码库不会敏捷。您可以在功能开发之前/期间进行TDD并编写测试，或者在功能开发之后编写功能的测试。但是，使用TDD方式通常更容易，更有效。

您可以敏捷，但是可能还有改进的空间。

敏捷的原则之一是，您必须能够应对变化。这意味着事先不知道要构建什么。如果您正在执行瀑布式流程，那么您将提前x个月确切地知道需要构建什么，并且可以设计单独的软件组件，以便它们各自参与更大的方案，从而最终形成产品（至少您会认为是这样）。但是，由于敏捷要求您不知道最终产品是什么，因此您永远都不知道您的代码将用于什么，更重要的是，何时更改它。

因此，您需要一个全面的测试套件，以确保在修改代码库后，您已经构建的功能可以继续使用。

但这本身不是TDD。如果在编写代码后编写测试，则不是TDD。但是TDD在另一个方面有所帮助，它可以防止生产过剩。

在我自己的敏捷团队中，我一直在努力与开发人员一起编写代码，他们认为这些代码在项目后期会变得有用。如果是瀑布式开发，那可能没问题，因为他们在接下来的x个月中为项目计划中的某些内容增加了支持。

但是，如果您遵循敏捷原则，则不应编写此代码，因为您甚至不知道这是否有必要。下周计划的功能可能会突然无限期地推迟。

如果您正确遵循TDD原则，那么在测试决定这行代码之前，单行代码就不可能存在（个人而言，我可以在不进行测试的情况下编写一些琐碎的代码），并且如果您从编写验收测试开始，那么您只能实现正是提供所需功能所需要的。

因此，TDD有助于避免生产过剩，从而使团队尽可能高效，这也是敏捷的核心原则。

工作软件是进度的主要衡量标准

您可以不进行TDD（测试驱动开发）而变得敏捷吗？

简短的回答：是的。

更长的答案：这个问题已经有很多非常好的答案，并且有很好的参考。我不会尝试辩论这些观点。

以我的经验，敏捷就是要为手头的项目选择合适的精益水平。精益是什么意思？而且，为什么要把它带入这个答案？

精益并不意味着将所有可能的方法都砍掉。正如我们的一位同事指出的那样，您不必在行为中包括TDD或单元测试。但是，在项目环境中您会发现自己，这可能有好处，也可能没有好处。

让我们考虑一下位于AK的一家大型无名零售商的供应链。有消费者。他们走进商店。商店通过卡车接收各种产品。据推测，卡车是从仓库中获得这些产品的。仓库中装满了来自各个制造商的货物。反过来，制造商则拥有整个供应链。

当上述供应链中的运输总经理被告知，如果他的车队中的卡车少于10辆，他每年将获得100万美元的年度奖金怎么办？他将立即将车队砍成9辆卡车。在这种“糟糕”的情况下，这将增加仓库中存储的货物数量（从而增加该节点中的成本）。而且，它将“饿死”商店的门面。

因此，如果允许本地优化而不考虑整体，那么整个供应链就会遭受损失。

返回到TDD和UT。TDD是一种需求表达机制。系统必须执行这些约束。很公平。TDD可以代替用例驱动开发的需求行为或用户故事驱动开发的需求行为。它具有结合单元测试和需求工作负载的“倾斜”优势。如果减少整体工作量，则将是一个好处。否，如果整个供应链的工作量增加了（让我们确定质量）。

因此，您问：如果不进行TDD（测试驱动的开发），您是否可以敏捷？

你当然可以。一个不同的，也许更好的问题是：-如果我将TDD应用于该项目，是否会导致总体上软件交付效率更高或效率更低？

引用喜欢的作者... JRR Tolkien

指环王。指环王团契。Pg 94“也有人说”，弗罗多回答，“不要向精灵寻求建议，因为他们不会，也不会。”

因此，最终，这取决于。您必须回答这个问题。哪条路径最有效地将您引向您的期望目标。

到TDD还是不到TDD。这仍然是问题。:-)

PS-我也在另一个网站上转发了这个答案。 https://www.ibm.com/developerworks/mydeveloperworks/blogs/c914709e-8097-4537-92ef-8982fc416138/?maxresults=15&sortby=4&lang=en

与设计城堡相比。

敏捷城堡

如果您要使用敏捷来设计城堡。您将编写具有特定功能的部分，并鼓励用户使用功能部分，从而根据用户的反应调整未来的设计。因此，您要构建地牢，并与地牢管理员进行通信，然后测试土地和地牢提供的基础。您会建造护栏，然后问守夜人是否很好。您将建造隔离墙并让士兵测试防御力。您将建造厨房，并让厨师们看一看。在此过程中，除当前结构外，迄今为止的每个部分都将起作用。因此，当您完成地牢时，可以将囚犯移入。依此类推。但是，当您最终完成城堡建造时，您会发现囚犯已经逃脱。

TDD城堡

使用TDD，您可以与囚犯一起出现，看看他们是否逃脱了。然后编写监狱牢房，直到牢房无法逃脱为止。然后，您将重构代码，从而干净地删除不需要的单元格，并删除错误位置的条形，然后再次进行测试。囚犯没有逃脱。您不必与看守通信。完成所有任务后，您便可以交付整个城堡。那时，狱卒说地牢需要更多的细胞，现在您必须挖掘更多的基础。

敏捷TDD城堡

如果将敏捷和TDD相结合。您会看到囚犯是否逃脱了，然后问囚犯需要什么。他说你需要更多的细胞。您会去找一些随机的人装作囚犯，看看他们是否逃脱了。如果他们不这样做，那么您可以将其显示给监狱长，他对此感到满意。然后，您开始构建护墙。

结论

因此，两者都解决了不同的问题。当用户看到产品在最容易适应的过程中发展时，敏捷便会根据发现他们的需求来帮助他们改变需求。它涉及释放从总体设计中分解出来的稳定添加项。

TDD解决了预期失败的问题。发现并纠正故障，该故障发生在最容易修复的过程中。它涉及测试从整体设计中分解出来的稳定的解耦代码单元。

可以很容易地将TDD视为对敏捷的扩展，因为它们都遵循相同的模式，单元驱动的进度并进行审查。区别在于，敏捷中的各个单元从整体上来说在外部发挥作用，而TDD中的各个单元则作为一个整体发挥作用，并且可能不会产生用于外部评审的功能性产品。并且这两个过程控制着不同的需求（可用性与正确性）。由于这两个功能都是以单元开发为基础的，因此两个审核过程都可以在相似的点进行，而TDD的划分更为精细。

笔记

• 仅进行单元测试并不意味着您使用TDD。TDD意味着在生产的单元之前进行测试，并在开发过程中使用该测试来确认该单元。没有TDD的单元测试可以用来确保您不会使以前构建的功能无效。
• 进行冲刺和其他会议不会使您敏捷。清单的目标使您变得敏捷。您可以将瀑布式目标分解成具有工作单元的sprint，而无需履行在流程上优先于人的承诺。
• 根据TDD和敏捷的定义。您的单元测试将控制不可交付的单元，因此TDD的循环速度将比敏捷的更快。如果同时使用两者，则您的敏捷周期将包含一个或多个TDD周期（如果每个单元都经过测试）。
• 据我了解：您未能通过为用户开发可交付的/有意义的单元而使敏捷失败。即使加快产品速度，该单元也可能有意义。但是，敏捷如何解释重构以简化维护？我还没有足够的答案。
• 您未通过单元测试而使TDD失败。产生无法正确产生功能的代码。

敏捷迫使您在每次迭代中解决和缓解计划和质量风险。即， 不需要将TDD视为敏捷。

但是，TDD是缓解质量风险的一项绝妙技术，特别是对于具有大量迭代或大量人员的项目而言。在这样的项目中，TDD将在早期迭代中增加一些计划风险，因为您也必须编写测试用例。但是，TDD可以在以后的迭代中节省大量成本，因为它可以不断降低质量风险。即建议使用TDD。