单元测试的过程

时间:2012-04-19 10:46:08

标签: unit-testing

好的,我知道单元测试是什么,但是我在一些项目中使用它而不是其他项目......一些客户不知道它是如何完成的并遵循一个约定......等等等等。

所以我在这里问,单元测试过程是如何创建的? 我听到并读到,您先编写测试然后编写功能并编写该功能的测试,并使用代码覆盖率来识别没有测试该代码的任何“滑动”,这些测试尚未涵盖。

所以,让我们使用一个简单的例子:

要求:“申请必须返回2个数字的结果。”

你和我知道我们会有一个类,比如“Addition”和一个方法“Add”,它返回一个如下的整数:

public class Addition
{
   public int Add(int num1, int num2)
   {
      return num1 + num2;
   }
}

但即使在写这门课之前,你又如何编写测试?你的过程是什么?你是做什么?当你拥有那个规范文档并进入开发阶段时,这个过程会是什么?

非常感谢,

1 个答案:

答案 0 :(得分:5)

您所指的流程称为Test-Driven Development。想法很简单,接近你所描述的;给定功能,您可以通过编写此功能的测试来开始编写代码。在您的添加示例中,之前编写任何正在运行的代码,您应该进行简单的测试 - 测试失败。

未通过测试

[Test]
public void TestAdd()
{
     var testedClass = new Addition();

     var result = testedClass.Add(1, 2);

     Assert.AreEqual(result, 3);
}

这是对.Add方法的简单测试,说明您对即将运行的代码的期望。由于你还没有任何代码,这个测试自然会失败(因为它应该 - 这很好)。

通过测试

下一步是编写最基本的代码,使测试通过(自然,最基本的代码是return 3;但是对于这个简单的例子,这个级别的细节是没必要):

public int Add(int num1, int num2)
{
    return num1 + num2;
}

这是工作和测试通过。你在这一点上所拥有的,基本证明你的方法在你的假设/期望(测试)中以你所说的方式工作。

但是,你可能会注意到这个测试不是很好;它只测试一个简单的输入数据。更不用说,在某些情况下,一个测试可能还不够,即使你有初始要求,测试可能会发现需要更多(例如参数验证或记录)。当你回到审查你的要求和编写测试时,这就是这个部分,这导致我们......

重构

此时你应该编写refactor代码。我正在谈论两个单元测试方法代码和测试实现。由于Add方法相当简单,并且在添加两个数字方面没有太多改进,因此您可以专注于更好地进行测试。例如:

  • 添加更多测试用例(或考虑数据驱动测试)
  • 使测试名称更具描述性
  • 改进变量命名
  • 将幻数提取为常量

像这样:

[TestCase(0, 0, 0)]
[TestCase(1, 2, 3)]
[TestCase(1, 99, 100)]
public void Add_ReturnsSumOfTwoNumbers(int first, int second, int expectedSum)
{
     var testedClass = new Addition();

     var actualSum = testedClass.Add(first, second);

     Assert.That(actualSum, Is.EqualTo(expectedSum));
}

重构是值得拥有的主题(也有很多),所以我不会详细介绍。我们刚刚经历的过程通常被称为 Red-Green-Refactor (红色表示测试失败,绿色表示通过),它是TDD的一部分。请记住再次重新运行测试,以确保重构不会意外破坏任何内容。

这是基本周期的方式。您从需求开始,为其编写失败测试,​​编写代码以使测试通过,重构代码和测试,审查要求,继续执行下一个任务。

从哪里开始?

一旦你了解了TDD背后的想法(即使从这篇文章中提供的简短解释),很少有有用的资源是良好的自然跟进: