Question

我已经阅读了一段时间的单元测试和功能测试。

如果我编写详尽的功能测试，它们是否也会覆盖下面的单元，这又会使单元测试变得多余？

我们遵循敏捷，一旦完成功能的“切片”，我们就会使用WebDriver编写功能测试，这通常是2-4周的冲刺时间。

Answer 1

也许，但不一定。

功能测试可以被认为是“黑匣子”测试，您可以在其中查看特定功能（无论是单个方法，模块，系统等），并检查对于给定输入，您获得给定输出

然而，如果功能测试失败，你只能说系统有问题;它不一定能给你任何关于系统的哪个部分的指示。当然，你会离开并诊断问题，但你不知道问题是什么。

e.g

//assuming you have a UserService that amongst other things passes through to a UserRepository
    var repo = new UserRepository();
    var sut = new UserService(repo);
    var user = sut.GetUserByID(1);
    Assert.IsNotNull(user); //Suppose this fails.

在上面的例子中，你不知道是不是因为UserService的GetUserByID()函数有问题 - 也许它没有调用repo.GetUserByID并且只返回null，也许它确实得到了{{1来自User然后意外地返回了一个未初始化的临时变量等 - 或许是因为依赖项（repo）本身有问题。无论如何，你必须调试这个问题。

另一方面，单元测试更像是“白盒”测试，您可以有效地从系统中取下封面并测试系统的行为，以便做您想做的事情它要做。

e.g。（以下代码可能无法编译，仅用于演示目的）

repo

在这种情况下，您明确地验证//setup a fake repo and fake the GetUserByID method to return a known instance: var repo = new Mock<UserRepository>(); var user = new User{ID=1;} repo.Setup(r=>r.GetUserByID(1).Returns(user); var sut = new UserService(repo.Object); var actual= sut.GetUserByID(1); //now make sure we got back what we expected. If we didn't then UserService has a problem. Assert.IsNotNull(user); Assert.AreEqual(user,actual);是否以预期的方式运行 - 它调用sut.GetUserByID()并返回结果对象，而不会对其进行修改或更改。

如果此单元测试通过，但功能测试失败，您可以放心地说问题不在于repo.GetUserByID()，而在于UserService类，甚至没有查看代码。这可能会或可能不会节省您的时间，这实际上取决于您的功能单元的复杂程度。

功能测试是单元测试的超集，是吗？

1 个答案: