单元测试能否通过敏捷开发有效实施？ [关闭]答案

【问题标题】：Can unit tests be implemented effectively with agile development? [closed]单元测试能否通过敏捷开发有效实施？ [关闭]
【发布时间】：2010-07-29 23:04:40
【问题描述】：

很快我将参与一个将使用敏捷项目管理/开发方法的项目，其中包含 5 个（左右）2 周的冲刺。该项目将使用我过去发现的 DDD 设计模式非常适用于单元测试，因此我也热衷于将它用于该项目。唯一的问题是以下因素，我不确定单元测试是否可以通过敏捷开发成功实施：

需求不断变化的可能性（需求变化、测试中断、测试也需要更新）。
时间因素（单元测试会使开发花费相当长的时间，如果在 sprint 结束时需求发生变化，则可能没有时间以最佳质量更新测试和生产代码）。

我有一种感觉，如果/当需求发生变化时（尤其是在 sprint 快结束时）并且考虑到紧迫的截止日期，单元测试将成为一种负担。有人对这件事有什么好的建议吗？

【问题讨论】：

这个问题是题外话，因为它不在本网站的范围内，如What topics can I ask about here? 中定义的那样另见：What types of questions should I avoid asking? 您可以在another Stack Exchange site 上提问，也许 Project Management 或Software Engineering。请务必阅读您打算发布问题的任何网站的帮助中心主题页面。
@Makyen 这个问题是在 7 年前发布的，当时这些其他交易所不存在/不为人所知，或者边界没有明确定义……所以，嗯……谢谢信息？多么奇怪的更新。
@Makyen 您是否真的在浏览最古老的旧帖子并根据当前的常见问题集提供建议？我的朋友，你还有很长的路要走！
我正在通过近距离投票审核队列。我不是从网站上挑选问题。但是，我没有使用一个固定的原因，虽然它可能也适用，但给人一种不准确的印象，即通过编辑问题可以使问题成为主题，我使用的是一个自定义原因，它实际上解释了这个问题不是该网站的主题。如上所述，使用自定义原因会导致将该原因作为评论发布。我认为这样做是对情况的诚实和直截了当。
是的，有一次这个问题可能是热门话题。多年来，Stack Overflow 的主题发生了变化。现在已经跑题了。这不应该对你产生不好的影响。这就是网站的变化。

标签： unit-testing tdd agile

【解决方案1】：

我认为它是双向的。一方面，是的，单元测试是额外的代码，需要额外的维护，并且会减慢你的速度。另一方面，如果需求开始变化，进行单元测试将是一个救命稻草，可以确保您所做的更改仍然有效。

【讨论】：

您的第二点是我书中最重要的一点。能够在知道系统的其余部分仍然正常工作的情况下安全地进行更改，使得进行这些更改变得更加容易。
我不认为 TDD 有很大的争议。大多数人都同意单元测试需要时间但有助于开发（通常收益大于成本），但并不是每个人都相信首先编写测试是有帮助的。首先编写测试作为一个设计过程具有价值，但它并不适合所有人。

【解决方案2】：

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

其次，良好的单元测试依赖于生产代码中极少的小功能块。如果这是真的，当一个特性发生变化时，只有少数测试会受到影响。基本上，每个测试只测试一件事和一小段生产代码。遵循这一原则编写单元测试的关键是解耦你的代码和独立的测试。

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

【讨论】：

【解决方案3】：

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

我不能强烈建议使用单元测试。即使在做 DDD 时，也要让单元测试驱动实现。再加上 DI/IoC 和 SRP 等良好模式，您应该会发现您的代码库和测试都更能适应变化，从而在这些 sprint 中为您节省大量时间。

【讨论】：

我从事需要数年时间且没有测试覆盖率的项目。不是我喜欢。一点也不。
@Peri - 我为你感到难过，可悲的是，许多项目都是这样的。希望没有太多的绿地项目开始吝啬自动化测试。不过现在还为时不晚，我收到了覆盖率为 0% 的系统，并且能够将其提升到 50%，随着它们经历新的变化，逐渐测试它们。