持续集成始终与测试驱动开发结合在一起？

Question

我参与了一个项目，我们正在使用Continuous Integration服务器和NUnit进行单元测试和集成测试。

前一天有客户问我们，如果我们在代码之前写测试......那么，是不是这样做总是这样。特别是当我们想要测试复杂的技术问题以首先了解问题和可能的解决方案时。

我想知道我们是否仍然可以将我们的开发流程视为遵循敏捷开发，对客户说，不要说谎。

Answer 1

我认为你在这里混合的东西。

测试驱动开发（TDD）并不一定意味着您正在使用敏捷方法。当然，最好的做法是我们许多使用敏捷的人，但TDD也可以用在瀑布过程中，替换/补充规范。

持续集成意味着让团队至少每天生成集成代码。这不仅会迫使团队中的每个成员不得不持续合并/签入，而且还会确保您实际上可以发布每个构建。统一构建过程会迫使您克服“在我的机器上操作”的问题。因为你可以每天都做一次发布，所以它支持一个敏捷的过程，即使它并不是严格意义上的绝对必要的。

使用测试并将它们集成到构建过程中是一种使用自动质量保证来丰富您的构建过程并深化实际测试集成（完整性）的级别的方法。

Answer 2

只要您在小型迭代中开发，关注于获得工作产品而不是获取大量文档，并且客户持续参与项目，那就是敏捷开发。单元测试，TDD和集成测试当然是好的和非常明智的做法，但他们并不决定您的项目是否敏捷。

Answer 3

在没有自动测试的情况下，CI仅验证源代码管理下的代码是否保持在修订版本之间的可编译状态，并且单步构建工作正常。虽然这很有用，但它不如自动验证那样有效，因为在修订之间代码的正确性得以维持。

说了这么多，我宁愿有一些检查之间的代码验证比没有。我宁愿有部分代码覆盖或一组不完整的功能测试。或更糟。