我想知道我们在大型产品中采用测试优先设计方法的可行性和实际收益。
尽管我坚信在进入编码之前要决定范围，但对于更大的产品，我真的不确定TDD是否成立。
较大产品的现实问题：
1。产品的大小使得维护所有测试用例变得更加困难
2.单元边界慢慢变得不那么明确，有时会在不同的单元之间产生不必要的耦合
3.测试一个单元可能不足以满足开发结构的功能(可能是紧密耦合的结果)
4。最初的思考过程和愿景可能会随着产品的尺寸而被淡化。这反过来稀释了单元的定义，测试用例变成了纯粹的过程需求，而不是为了成为代码的守护者。
我的观点是，这种产品增长的情况是停止产品的增长并去除不需要的部分。开始清理产品，使其仅具有定义产品的那些功能。其他功能，无论是已经开发的还是正在开发的，都可以作为插件提供。产品的这些核心功能集需要使用一组强大的单元测试用例进行保护，这些用例单独定义单元的功能。
还有什么建议吗？我很想听听你们的意见，因为我目前面临着单元耦合和冗余测试用例的情况，而这些情况实际上并没有多大作用。所有这些都是由于产品的规模几乎每天都在增长。
- TDD适用于任何规模的项目。就我个人而言，在我最后一次统计时，我使用了一个大约65万行C Sharp的系统。如果没有一套测试来支持我们的变化并防止倒退，我们永远不会达到这样的规模
- 记住测试优先和测试驱动(TDD)之间的区别。如果您遵循测试驱动的开发，并让测试驱动您创建的代码，那么耦合应该不是问题。TFD的情况就不一样了，这将由开发人员来控制质量水平
- 参见第一点。事实上，单元测试将是任何地方高级功能的最佳选择。查看这篇文章，了解代码中每个路径需要多少测试。您可以使用集成测试，但正如文章所指出的，您需要的数量将超过您需要的单元测试数量
- 这取决于团队。测试代码应该被视为一等公民。如果项目要像你想象的那样"大"，这一点尤其正确，最轻微的回归可能代价高昂
关于您的最后一个问题，我的建议是确保您的核心域逻辑尽可能经过测试和稳定。这将取决于您和您的团队来找出您的应用程序的"核心"是什么。剩下的基础设施可能相当松散，但无论如何，这一层应该几乎没有逻辑。锁定域名，其他人也应该效仿。