我参加过许多尝试练习敏捷方法的团队，而这些团队通常都是以测试为中心的。测试是实践敏捷方法学的必要组成部分，还是仅仅是多年来积累下来的XP实践？

测试对于敏捷是绝对必不可少的，主要是因为敏捷是基于渐进式改进的：困难之处在于有时很难看到当前的更改将如何影响您的旧代码。确信自己没有损坏某件东西的最佳方法是对其进行测试，并知道如何进行测试。这样一来，您就可以立即发现错误，而不必在忘记编写代码时的确切操作时发现错误。

这与更传统的，自上而下的设计类型编程不同的原因是，在这种环境下a）在完成成品之前很难进行测试b）理论上您正在同时考虑所有设计准则，并且因此您不太可能做出违反先前设计决策的设计决策。

您可能在谈论自动化测试，单元测试，集成测试等。这些敏捷性比手动测试（使用测试器等）对敏捷性更为重要，因为它们太慢了，因此不可能测试您所做的每一个小更改。由于敏捷是指快速的小迭代，因此使用能够在几秒钟或几分钟而不是几小时或几天内验证正确性的测试非常有用。

如果您没有测试，怎么知道您的代码有效？

编辑：测试无法证明代码有效的断言未能定义一个关键术语，即work。程序正常工作意味着什么？如果您对这个术语含糊不清，则根本无法证明或确保任何程序都能正常工作。曾经

另一方面，您可以将作品定义为“根据规范的行为”。现在，您不仅可以使用测试来证明代码可以工作，而且测试本身可以用作代码行为的可执行规范。换句话说，写得很好的测试套件定义了有效的含义。

这种思维方式也迫使您重新检查错误的含义。如果您的代码通过了所有测试，则代码中没有错误。尽管如此，如果系统仍无法正常运行，则无法正确指定其行为。即 该错误在规范中，由测试定义。

这种软件开发方法使系统的功能规范与其实现脱钩，根据世界上每本软件工程书籍，这都是一件好事。同时，这种方法可确保您的实现始终符合功能规范。

不，这是没有必要的”

在敏捷的原则，什么都不说直接有关测试。

但这是极可取的

鉴于敏捷对可持续过程，持续/递增交付和软件质量的承诺，自动化测试是当前可用于大多数项目的最佳解决方案

异常（如JörgW Mittag所述）包括可证明正确的开发工具，生成代码的元编程系统等。但是这类系统很少见。

敏捷和XP都试图避免提前大设计。在BDUF中，收集需求，创建正式规范，然后进行编码，然后进行测试。这对于定义明确，对任务和生命至关重要的系统（如医疗设备，太空探测器等）有意义。

敏捷避免了这种流程，因为它不适用于定义不明确的问题，例如“客户本周要求进行的任何更改”。我们仍然需要一个正式的规范，所以我们知道该做什么和什么时候完成，但是我们不是使用某种书面文档，而是使用自动化测试形式的代码。

自动化的单元测试可以快速编写，快速运行并且非常模块化/分离。这使它们成为正式指定和检查需求的快速方法。