单元测试能用敏捷开发有效地实现吗？

Question

很快，我将参与到一个使用敏捷项目管理/开发方法的项目中，该项目有5(约)个星期的冲刺。该项目将使用DDD设计模式，这是我在过去发现的伟大工程与单元测试，因此我有热情使用它为这个项目以及。唯一的问题是，考虑到以下因素，我不确定是否可以通过敏捷开发成功地实现单元测试：

• 用于不断变化的需求(需求变化、测试中断、测试也需要更新)。
• 时间因素(单元测试可以使开发人员花费相当长的时间，如果需求在冲刺结束时发生变化，那么更新测试和生产代码的时间可能太少，质量最好)。

我有一种感觉，如果/什么时候需求发生变化(特别是在冲刺接近尾声的时候)，并且考虑到紧迫的截止日期，单元测试将成为一种负担。有人在这件事上有什么好建议吗？

Answer 1

我觉得这是两全其美的。一方面，是的，单元测试是额外的代码，需要额外的维护，并且会使您慢一点。另一方面，如果需求开始演变，让单元测试就位将是确保您正在更改的内容仍然有效的一个生命保护程序。

Answer 2

考虑到10+数周的代码，没有测试覆盖率，我感到很害怕。您什么时候有时间手动测试所有这些代码？在不断变化的需求下，您将使用更多的时间来跟踪更改对整个代码库的影响。

我无法给出足够有力的建议来使用单元测试。即使在执行DDD时，也让单元测试驱动实现。再加上DI/IoC和SRP这样的好模式，您应该会发现您的代码库和测试能够更好地适应变化，从而节省了您在冲刺过程中的大量时间。

Answer 3

除非您有高覆盖率的单元测试，否则随着项目的推进，更改的成本将成倍增长。因此，基本上，您预期的更改越多，您实际上就越需要单元测试。

其次，好的单元测试依赖于产品代码中很少的和很小的特性片段。如果这是真的，当一个特性发生变化时，只有少数几个测试会受到影响。基本上，每个测试只测试一件事情和一小部分生产代码。编写遵循此原则的单元测试的关键是将代码解耦并进行隔离测试。

第三，你需要更好地理解“做”的概念，以及为什么它的定义在可持续发展方面如此重要。基本上，如果您的团队在短期内将“完成”的概念相结合，您就不能以一种可持续的方式快速前进。