unit-testing - 对大型应用程序进行单元测试 - 经过验证的方法？

Question

在过去的 10 个月里，我一直在研究 Windows 窗体应用程序和 ASP.Net 应用程序。我一直想知道如何以涵盖所有场景的稳健方式对完整的应用程序执行适当的单元测试。我有以下关于他们的问题-

• 有哪些标准机制 执行单元测试和编写测试用例？
• 方法是否根据 关于应用程序的性质，例如 Windows 窗体、Web 应用程序等？
• 最好的方法是什么 确定我们涵盖了所有场景吗？任何 这方面的热门书籍？
• 执行单元的常用工具 测试？

Answer 1

我推荐一本关于这个主题的好书:Working Effectively with Legacy Code由迈克尔羽毛。我发现它对类似的遗留项目非常有用。

遗留代码的主要问题是没有“标准”方法对其进行单元测试:-(“标准”测试驱动开发是为新项目发明的，您可以从头开始编写代码和单元测试，因此您可以从第一天起就将单元测试套件与您的代码一起扩展，并始终覆盖所有(或大部分)代码。

然而，现实是大多数现实生活中的项目都涉及遗留代码，而没有进行任何单元测试(事实上，Feathers 对遗留代码 的定义是“没有单元测试的代码”)。这本书充满了有用的建议，告诉你当你需要接触你几乎看不懂的代码时该怎么做，或者修改一个 1000 行的怪物方法并确保至少你的修改得到正确的单元测试。在这种情况下，通常很难编写单元测试，因为代码并非设计为可测试的。因此，您经常需要重构它以使其可测试，但当然，如果没有适当的单元测试，这是有风险的……尽管如此，还是有办法摆脱这些陷阱的，本书展示了它们。

一般来说，你不应该以覆盖整个代码库为目标(除非你有一个项目经理愿意接受你在接下来的几个月 - 或几年内不会产生任何新功能;- ).您只有有限的时间从单元测试中获得最大可能的好处。因此，您必须首先关注代码中最关键的部分。这些通常是最常修改的和/或发现最多错误的那些(当然存在相关性)。您可能还提前知道即将推出的功能需要扩展代码的特定部分，因此您可以通过为其创建单元测试来做准备。这样，随着时间的推移，您开始在代码中形成小的“安全岛”，单元测试可以更好地覆盖这些安全岛。这些地方的维护和重构更容易，并且随着您添加更多单元测试，孤岛会慢慢增长...

请注意，一开始这些“安全岛”并不倾向于显示出非常“系统”的发生模式。代码中最关键、最常修改的部分通常相当随机地分布。只有在很晚的阶段，当单元测试的孤岛开始增长和合并时，才值得更系统地覆盖特定模块。例如。如果您发现在这个特定模块中，单元测试的代码覆盖率增长了 60% 以上，您可能会决定检查它并为其余代码部分也添加测试。