我们有一个项目开始变大，我们需要在开始重构时开始应用单元测试。将单元测试应用于已经存在的项目的最佳方法是什么？我（在某种程度上）习惯于从头开始，在那里我与第一行代码一起编写测试。当功能已经到位时，我不确定如何开始。我应该开始为存储库中的每个方法编写测试吗？还是应该从控制器开始？
更新： 澄清项目的规模.. 除了说有 8 个控制器和大约 167 个具有 .cs 扩展名的文件之外，我真的不确定如何描述这一点，所有这些都在大约 7 个开发人员月内完成..
【问题讨论】：
标签： c# asp.net-mvc unit-testing
对于具有适当规模的代码库的遗留项目，由于预算限制等原因，对所有内容进行单元测试可能不是合理的努力。根据我对这个主题的阅读，我建议：
每个泄露到 QA、发布或生产环境的错误都是编写单元测试用例和修复错误的候选者。
使用源代码管理来找出代码库的哪些部分/文件比其他部分更频繁地更改。将这些部分/文件置于单元测试覆盖范围内。
新故事开发应该有针对它们编写的有意义的单元测试用例。
继续监控单元测试覆盖率，以观察代码库特定区域的任何下降趋势。该区域需要您放大并查看单元测试覆盖率是否正在失去其有效性。
P.S.：我已将 Michael Feathers 的书添加到我的阅读清单中，感谢您的建议。
【讨论】：
有很多方法可以围绕现有代码库进行测试。单元测试不一定是最有效的开始方式。如果您编写了大量代码，那么在深入到单元测试级别之前，您可能需要考虑功能和集成测试。这些更高级别的测试将帮助您广泛确保您的产品在您进行更改以改进结构和改进单元测试时继续工作。
在您的情况下，我强烈推荐非测试优先组织使用的一种做法是：让原始代码部分的作者以外的其他人为该部分编写单元测试。这可以让您进行一定程度的交叉训练和健全性检查，还有助于确保您不会保留会损害您的代码整体的假设。
除此之外，我将支持 Michael Feathers 的书的推荐。
【讨论】：
您似乎知道，将测试改型到现有项目中并不容易。您编写测试的方法是更好的方法。您的问题是过程和技术之一 - 每个人都必须要求进行测试，否则没有人会使用它们。
我听到并同意的建议是，您不应该尝试一次将测试包装在现有代码库中。你永远不会完成。首先在您的错误修复过程中进行测试 - 每个已修复的错误都会进行测试。随着时间的推移，这将开始对您现有的代码进行测试。当然，新代码必须始终进行测试。最终，您可以将覆盖率提高到合理的百分比，但这需要时间。
我推荐给我的一本好书是 Michael C. Feathers 的 Working Effectively With Legacy Code。书名并未真正说明这一点，但对现有代码库进行测试是本书的主要主题。
【讨论】：