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

Question

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

前几天，客户问我们是否在代码之前写了测试......好吧，他们总是不这样做。特别是当我们想要测试复杂的技术问题时，首先要了解问题和可能的解决方案。

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

Answer 1

我认为你在这里搞混合了。

测试驱动开发（TDD）并不一定意味着您正在使用敏捷方法。当然，我们许多敏捷使用的人都是最佳实践，但TDD也可用于瀑布流程，替代/补充规范。

持续集成本身意味着让您的团队至少每天生成集成的代码。这不仅会迫使团队中的每个成员不断合并/签入，而且还会确保您实际上可以发布每个构建版本。统一构建过程会强制您克服“在我的计算机综合症上工作”。因为你每天都可以发布一个版本，所以它支持敏捷过程，即使从严格意义上说它并非绝对必要。

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

Answer 2

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

Answer 3

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

话虽如此，我宁愿在签到之间进行一些代码验证，而不是没有。我宁愿有部分代码覆盖或一组不完整的功能测试。或者更糟。