1

我想知道我们在大型产品中遵循“测试优先设计”方法所获得的可行性和实际收益。

尽管我坚信在开始编码之前确定范围，但对于更大的产品，我真的不确定TDD是否成立。

较大产品的实际问题：
1. 产品的大小使得维护所有测试用例变得更加困难。
2. 单元边界逐渐变得不那么明确，有时会在不同单元之间产生不希望的耦合。
3. 测试一个单元可能不足以满足所开发结构的功能本身（紧密耦合的可能结果）
4. 最初的思考过程和愿景可能会随着产品大小而被稀释。这反过来又淡化了单元的定义，测试用例变成了单纯的过程需求，而不是成为一段代码 的守护者。

我的观点是，这种产品增长的情况是停止产品的增长并删除不需要的部分。开始清理产品以仅具有定义产品的那些功能。已经开发或正在开发的其他功能可以作为插件提供。产品的这些核心功能集需要使用一组强大的单元测试用例来保护，这些用例单独定义了单元的功能。

还有什么建议吗？我很想听听你们的意见，因为我目前正面临这种单元耦合的情况和实际上并没有多大作用的冗余测试用例。所有这些都是由于产品的规模几乎每天都在增长而引入的。

4

1 回答 1

1
  1. TDD 适用于任何规模的项目。我个人在一个系统上工作，根据我的最新统计，大约有 650,000 行 C Sharp。如果没有一套测试支持我们的更改并防止回归，我们永远不会接近这样的规模。
  2. 请记住测试优先和测试驱动 (TDD) 之间的区别。如果您遵循测试驱动开发并让测试驱动您创建的代码，那么耦合应该不是问题。对于 TFD 则不能这样说，这将取决于开发人员来控制这种质量水平。
  3. 见第一点。事实上，单元测试将是任何地方的高级功能的最佳选择。查看这篇文章，了解代码中每个路径需要多少测试。您可以使用集成测试，但正如文章指出的那样，您需要的数量将超过您需要的单元测试数量。
  4. 这取决于团队。测试代码应该被视为一等公民。如果项目要像您认为的那样“大”，则尤其如此，最轻微的回归可能代价高昂。

关于您的最后一个问题，我的建议是确保您的核心域逻辑尽可能经过测试和稳定。您和您的团队将决定您的应用程序的“核心”是什么。剩余的基础设施可能相当松散，但无论如何，这一层应该几乎没有逻辑。锁定域，其余的应该效仿。

于 2013-02-17T14:44:48.843 回答