可以通过敏捷开发有效地实施单元测试吗?

时间:2010-07-29 23:04:40

标签: unit-testing tdd agile

很快,我将参与一个将使用敏捷项目管理/开发方法的项目,其中包括5周(或大约)2周的冲刺。该项目将使用我在过去发现的DDD设计模式,非常适合单元测试,因此我也非常热衷于将此项目用于此项目。唯一的问题是以下因素我不确定是否可以通过敏捷开发成功实现单元测试:

  • 不断变化的需求的潜力(需求变化,测试中断,测试也需要更新)。
  • 时间因素(单位测试可以使开发人员花费更长的时间,如果需求在冲刺结束时发生变化,则可能没有太多时间以最佳质量更新测试和生产代码。)

我感觉如果/当需求发生变化时(特别是在冲刺结束时)并且在紧迫的期限内,单元测试将成为负担。有人对此事有任何好的建议吗?

3 个答案:

答案 0 :(得分:7)

我认为它会削减两种方式。一方面,是的,单元测试是额外的代码,需要额外的维护,并会减慢你的速度。另一方面,如果需求开始发展,那么进行单元测试将有助于确保您所做的更改仍然有效。

答案 1 :(得分:3)

考虑到10周以上的代码没有测试覆盖率让我感到畏缩。您什么时候有时间手动测试所有代码?在不断变化的需求下,您将花费更多时间来跟踪整个代码库中的更改所带来的影响。

我不能强烈建议使用单元测试。即使在进行DDD时,也要让单元测试推动实施。再加上像DI / IoC和SRP这样的良好模式,你应该发现你的代码库和测试对变化更具弹性,从而在这些冲刺中节省大量时间。

答案 2 :(得分:3)

除非您拥有高覆盖率的单元测试,否则随着项目的推进,变更成本将呈指数级增长。所以基本上,你预期更多的变化你实际上需要你的单元测试。

其次,良好的单元测试取决于生产代码中的极少数特征。如果是这样,当功能发生变化时,只会影响一些测试。基本上,每个测试只测试一件事和一小块生产代码。编写遵循这一原则的单元测试的关键是将代码解耦并单独测试。

第三,你需要更好地理解DONE的概念,以及为什么它的定义在可持续发展方面如此重要。基本上,如果你的团队在短期内损害了DONE的概念,你就无法以可持续的方式快速前进。