【发布时间】：2009-11-03 07:45:27
【问题描述】：
我参与了一个项目，我们使用持续集成服务器和 NUnit 进行单元测试和集成测试。
前几天，一位客户问我们是否在编写代码之前编写测试......嗯，我们并不总是这样做。特别是当我们想要测试复杂的技术问题以首先了解问题和可能的解决方案时。
我想知道我们是否仍然可以将我们的开发过程视为遵循敏捷开发，对客户说出来，不要撒谎。
【问题讨论】：
标签： c# continuous-integration agile
【发布时间】：2009-11-03 07:45:27
【问题描述】：
我认为你在这里搞混了。
测试驱动开发 (TDD) 并不一定意味着您正在使用敏捷方法。当然，我们许多从事敏捷开发的人都在使用它是一种最佳实践，但 TDD 也可以用于瀑布流程，替换/补充规范。
持续集成本身意味着至少每天集成您的团队生成的代码。这不仅迫使团队的每个成员都必须不断地合并/签入，而且还确保您实际上可以发布每个构建。统一的构建过程迫使您克服“在我的机器上工作综合症”。因为你可以每天发布一个版本，这支持了一个敏捷过程，尽管从严格意义上来说它并不是绝对必要的。
使用测试并将它们集成到构建过程中是一种通过自动化质量保证来丰富构建过程并加深实际测试集成（完整性）水平的方法。
【讨论】：
只要您在小迭代中进行开发，专注于获得工作产品而不是获得大量文档，并且客户持续参与项目，这就是敏捷开发。单元测试、TDD 和集成测试当然是很好且非常可取的做法，但它们并不能决定您的项目是否敏捷。
【讨论】：
在没有自动化测试的情况下，CI 仅验证源代码控制下的代码在修订之间保持可编译状态，以及单步构建是否正常工作。虽然这很有用，但它不如自动验证代码的正确性在修订之间得到维护。
话虽如此，我宁愿在签入之间对代码进行一些验证，而不是没有。我宁愿有部分代码覆盖或一组不完整的功能测试，也不愿什么都没有。或者更糟。
【讨论】：