在现有代码库中开始自动集成/单元测试

时间:2010-07-27 21:19:21

标签: c# unit-testing nunit mstest xunit.net

背景:我们已经交付了一个非常大的代码库(140万行),主要是在C#中。该应用程序主要包括访问SQL Server 2008数据库中的数据以及各种XML文件的asp.net 2.0样式asmx Web服务。没有现有的自动化测试。我们有一个自动化的夜间构建(CC.NET)。

我们希望引入一定程度的自动化测试,但是对于这一代码量的粒度级单元测试进行重构似乎不太可能。我们的第一个想法是找到一种方法来构建自动化测试,只需使用给定的参数集调用每个Web服务,以便为我们提供一定程度的代码覆盖率。似乎是通过一些自动化测试获得最高代码覆盖率的最快方法。这甚至被称为单元测试还是会被认为是别的?

如何隔离数据存储以获得一致的测试结果?任何测试工具都会比其他测试工具更好地适应这种方法的xUnit? MS测试? NUnit的?

任何让我们开始朝正确方向前进的建议都将不胜感激。感谢

4 个答案:

答案 0 :(得分:11)

我的公司一直在做类似于我们的代码库(C而不是C#),总共大约一百万行。这些步骤是这样的:

1)编写一些自动化测试,就像你描述的那样进行系统级测试 2)实施新代码应进行单元测试的规则 3)当一个区域有一些错误时,修复这些错误的过程应该包括编写一个基本的单元测试。

关键是3不应该要求完整的单元测试(如果人们更容易做到这一点)。如果您从0%的测试覆盖率转移到特定模块的40%覆盖率,那么您已经取得了很大的进步。

虽然6个月内你可能只占总代码库的5%,但是5%是变化最大的代码,而你最有可能引入bug。我现在使用的代码大约60%由集成测试覆盖,15%(按行)覆盖单元测试。这似乎不是很多,但它确实提供了重要的价值,我们的开发工作也从中受益。

编辑:为了响应其他评论之一,我们运行的当前集成测试集当前大约需要14个小时。我们现在正在考虑并行运行一些以加速它们。

答案 1 :(得分:4)

严格来说,您描述的测试听起来更像是端到端或集成测试,而不是单元测试。但这不一定是坏事!在您的情况下,从端到端测试到单元测试 down ,而不是像新代码库那样 up ,这可能会很有效。< / p>

  1. 为每个Web服务API编写至少一个简单测试,以确保您对所有内容进行了一些覆盖
  2. 根据过去的错误报告,确定历史上容易出现故障的API。为这些API编写更广泛的测试。
  3. 每次遇到测试失败时,请下拉一个级别并为该代码路径上调用的方法编写测试。最终你会发现其中一个测试失败了。如果该级别的bug不明显,请下拉级别并重复。
  4. 每次收到新的错误报告时,请冲洗,清洗,重复。
  5. 这里的想法是,您根据当前容易出现故障的代码路径“按需”引入单元测试覆盖率。这将加强未来的代码路径,并将逐步扩展整个应用程序的单元测试覆盖率。

答案 2 :(得分:0)

正如JSBangs指出的那样,那些是调用集成测试。我同意集成测试对于你的案例来说是更好的单元测试。有140万行代码,我不确定你可以从代码库中单独测试什么。

为了隔离数据存储,我喜欢这样做:

  1. 从最初开始使用一组硬编码数据

  2. 过了一段时间,您应该进行实际创建一堆测试数据的测试。首先运行这些测试,您不再需要硬编码数据。

  3. 当由于一组“错误数据”而导致生产出现问题时,请将其添加到测试中。最后,您将获得一组测试数据,用于测试大多数情况。

  4. 另外,请记住集成测试需要更长时间才能运行。您可能希望在测试计算机上运行它们,因此它不会阻止您的计算机。对于需要数小时才能运行的测试套件来说,这是很正常的。

答案 3 :(得分:0)

您可以看到的一件事是使用SpecFlow之类的用户故事。我发现这些故事更自然地映射到集成测试,这就是你想要的。使用这些的额外好处是它创建了一组几乎可以由技术以外的团队使用的用例(即产品管理/业务分析师)。