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