我有一个由 5 个 C# 库组成的现有框架，该框架自 2006 年以来一直得到很好的使用，并且是我大部分项目的主要代码库。出于软件质量的原因，我的公司希望推出 TDD；通过学习许多教程并阅读理论，我了解了 TDD 的好处。
时间不是无限的，我需要为此制定务实的计划。据我所知，我看到的选项是:
A) 可以使用一个测试项目来重叠来自所有 5 个库组件的对象。一系列高级测试可能是最初被视为非常大的软件库的起点。
B) 5 个库组件中的每一个的测试项目。这些项目将在与其他库组件隔离的最低级别上测试功能。
C) 由于代码被广泛认为是有效的，因此只对错误修复或新功能添加单元测试。编写一个测试，该测试在包含错误的逻辑上失败，并包含重现错误的步骤。然后重构代码直到测试通过。现在您可以确信错误已修复，并且不会在以后的周期中引入
无论选择哪个选项，都可能需要“模拟”来替换外部依赖项，例如:
- 数据库
- 网络服务
- 配置文件
如果有人有更多意见，这将非常有帮助。 我计划在 Visual Studio 2010 中使用 Microsoft 的内置 MSTest。
最佳答案
我们有一百万行代码库。我们的方法是从编写一些集成测试开始(您的选项 A)。这些测试几乎端到端地运行整个系统:它们从存储库复制数据库文件，连接到该数据库，对数据执行一些操作，然后将报告输出为 CSV，并将它们与已知良好的输出进行比较。它们远非全面，但它们执行了大量我们的客户依赖我们的软件来完成的事情。
当然，这些测试运行得非常慢；但六年后我们仍然连续运行所有这些程序(现在分布在八台不同的机器上)，因为它们捕获了我们仍然没有单元测试的东西。
一旦我们有了一个不错的集成测试基础，我们就会花一些时间围绕系统的高流量部分添加更细粒度的测试(您的选项 B)。我们有时间这样做，因为人们认为我们的代码质量很差。
一旦我们将质量提高到某个阈值，他们就开始要求我们再次进行实际工作。所以我们适应了为新代码编写测试的节奏(你的选项 C)。此外，如果我们需要对尚未进行单元测试的现有代码进行更改，我们可能会在开始进行更改之前花一些时间用测试覆盖现有功能。
您的所有方法都有其优点，但随着时间的推移，随着您获得测试覆盖率，相对 yield 将会发生变化。对于我们的代码库，我认为我们的策略是好的；集成测试将有助于捕获您在尝试打破依赖关系以添加单元测试时犯下的任何错误。
关于c# - 将 TDD 追溯应用到 C# 代码库中的最佳选择，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/7715959/