背景：我们收到了一个非常大的代码库（140 万行），主要是 C#。该应用程序主要由 asp.net 2.0 样式的 asmx Web 服务组成，该服务访问 SQL Server 2008 数据库中的数据以及各种 XML 文件中的数据。没有现成的自动化测试。我们有一个自动化的夜间构建 (CC.NET)。
我们想引入某种程度的自动化测试，但针对这么多代码在粒度级别的单元测试中重构似乎不太可能。我们的第一个想法是找到一种方法来构建自动化测试，只需使用给定的一组参数调用每个 Web 服务，从而为我们提供一定程度的代码覆盖率。似乎是通过一些自动化测试获得最高代码覆盖率的最快方法。这甚至被称为单元测试还是会被视为其他东西？
如何隔离数据存储以获得一致的测试结果？是否有任何测试工具比其他工具更适合这种方法？单位？质谱测试？单元？
我们将不胜感激任何能让我们朝着正确方向开始的建议。谢谢
【问题讨论】：
标签： c# unit-testing nunit mstest xunit.net
我的公司一直在使用我们的代码库（C 而不是 C#）做类似的事情，总行数约为一百万行。步骤是这样的：
1) 编写一些像您描述的那样进行系统级测试的自动化测试。
2) 实现新代码必须有单元测试的规则。
3) 当一个领域有一些错误时，修复这些错误的过程应该包括编写一个基本的单元测试。
关键是 3 不应该需要完整的单元测试（如果它更容易人们会这样做）。如果您将特定模块的测试覆盖率从 0% 提高到 40%，那么您已经取得了很大的进步。
尽管在您的 6 个月内可能只占总代码库的 5%，但 5% 是变化最多的代码，也是您最有可能引入错误的地方。我现在处理的代码大约 60% 被集成测试覆盖，15%（按行）被单元测试覆盖。这看起来不多，但它确实提供了巨大的价值，我们的开发工作也从中受益。
编辑：目前我们运行的一组集成测试需要大约 14 小时才能响应其他 cmets 之一。我们现在正在考虑并行运行一些以加快它们的速度。
【讨论】：
严格来说，您描述的测试听起来更像是端到端或集成测试，而不是单元测试。但这不一定是坏事！在您的情况下，down 从端到端测试转向单元测试，而不是像在新代码库上那样up，可能会更有成效。
这里的想法是您“根据需要”沿着当前容易失败的代码路径引入单元测试覆盖率。这将在未来强化这些代码路径，并将逐步扩大您的单元测试覆盖整个应用程序。
【讨论】：
正如 JSBangs 所指出的，这些都是所谓的集成测试。而且我同意集成测试比您的案例更好的单元测试。由于有 140 万行代码，我不确定您可以从该代码库中对什么进行单元测试。
为了隔离数据存储，我喜欢执行以下操作：
最初有一组硬编码数据
一段时间后，您应该有一个实际创建一堆测试数据的测试。首先运行这些测试，您不再需要硬编码数据。
当生产中由于一组“错误数据”而出现问题时，请将其添加到您的测试中。最终，您将拥有一组可以测试大多数情况的良好测试数据。
另外，请记住，集成测试需要更长的时间才能运行。您可能希望在测试机器上运行它们，这样它就不会阻塞您的计算机。运行需要数小时才能运行的测试套件是很正常的。
【讨论】：
您可以查看的一件事是使用 SpecFlow 之类的用户故事。我发现这些故事更自然地映射到集成测试，这正是您想要的。使用这些的额外好处是它创建了一组几乎可以由非技术团队（即产品经理/业务分析师）使用的用例。
【讨论】：