如何在大型项目中进行单元测试

Question

我们有一个项目开始变大，我们需要在开始重构时开始应用单元测试。将单元测试应用于已存在的项目的最佳方法是什么？我（有点）习惯于从头开始这样做，在那里我将测试与第一行代码一起编写。当功能已经到位时，我不确定如何启动。我应该从存储库开始为每个方法编写测试吗？或者我应该从控制器开始？

更新 澄清项目的大小..我不确定如何描述这个除了说有8个控制器和大约167个扩展名为.cs的文件，所有这些都在大约7个开发人员月完成..

Answer 1

您似乎意识到，将测试改装到现有项目并不容易。您随时编写测试的方法是更好的方法。您的问题是流程和技术之一 - 每个人都必须要求测试，否则没有人会使用它们。

我听到并同意的建议是，您不应该尝试一次性围绕现有代码库进行测试。你永远不会完成。首先对您的错误修复过程进行测试 - 每个修复的错误都会得到一个测试。随着时间的推移，这将开始测试您现有的代码。当然，新代码必须总是进行测试。最终，你将覆盖率达到合理的百分比，但这需要时间。

我推荐给我的一本好书是Michael C. Feathers Working Effectively With Legacy Code。标题并没有真正证明它，但是对现有代码库进行测试是本书的主要内容。

Answer 2

有许多方法可以围绕现有代码库进行测试。单元测试不一定是最有效的开始方式。如果您编写了大量代码，那么在进行单元测试级别之前，您可能需要考虑功能和集成测试。这些更高级别的测试将帮助您广泛保证您的产品在进行更改以改进结构和改进单元测试时继续工作。

在我的情况下，我非常推荐的非测试优先组织使用的一种做法是：让原始代码部分的作者以外的其他人编写该部分的单元测试。这可以为您提供一定程度的交叉训练和健全性检查，还有助于确保您不会保留会对您的代码造成损害的假设。

除此之外，我将推荐Michael Feathers的书。

Answer 3

对于具有适当大小的代码库的旧项目，由于预算限制等原因，对所有单元进行测试可能并不是合理的工作量。根据我对此主题的阅读，我建议：

1. 每个已泄漏到QA，Release或Production环境中的bug都是编写单元测试用例以及修复bug的候选人。

2. 使用源代码控制来找出代码库中哪些节/文件比其他节/文件更频繁地进行更改。将这些部分/文件置于单元测试范围之内。

3. 新故事开发应该针对它们编写有意义的单元测试用例。

4. 保持监视单元测试范围，以观察代码库特定区域中的任何下降趋势。此区域需要您放大并查看单元测试范围是否正在失去有效性。

P.S .：感谢您的建议，我已将Michael Feathers的书添加到我的阅读清单中。