unit-testing - 单元测试 - 测试用例与多种方法

Question

在为下面的示例编写单元测试时，最好的做法是使用 TestCases(例如在 NUnit 中)，还是编写多个测试来验证功能？

假设您要测试下面的 RetrieveContact 方法 - 它只是在数组中查找相应的联系人并在找到时返回结果，否则将返回 null。

public class Contact
{
    public string Name { get; set; }
}

private static Contact[] Contacts =
{
    new Contact() { Name = "Jim" },
    new Contact() { Name = "Bob" },
    new Contact() { Name = "Tom" }
};

public static Contact RetrieveContact(string name)
{
    return Contacts.FirstOrDefault(c => c.Name == name);
}

你会用一种方法测试它吗，使用 TestCases，如下所示？

[TestCase("Bob", "Bob")]
[TestCase(null, "ZZZ")]
public void Test_RetrievesFromContacts(string expectedName, string name)
{
    var ret = RetrieveContact(name);
    Assert.AreEqual(expectedName, ret?.Name);
}

或者您会编写两个单独的测试 - 一个用于有效联系人，一个用于返回 null 的无效联系人？

[Test]
public void Test_RetrieveValidContact()
{
    var ret = RetrieveContact("Bob");
    Assert.AreEqual("Bob", ret.Name);
}

[Test]
public void Test_RetrieveInvalidContact()
{
    var ret = RetrieveContact("ZZZ");
    Assert.AreEqual(null, ret);
}

谢谢

Answer 1

JUnit 中的惯例是每个单元 测试都应该测试一个特定的功能，一个通过被测代码的不同路径。此约定强烈暗示您不应将多个不相关的测试组合到一个测试方法中。

因此，在上面的示例中，您将为以下各项编写一个测试:

• 一个用于有效联系人
• 一个用于无效联系人

这样做的理由是:

• 如果您将上述两个测试路径组合成一个测试，那么第一个路径中的失败可能会阻止第二个路径运行(从而降低测试覆盖率)
• 在所有其他条件相同的情况下，细粒度的测试用例可能更简洁易读，即不太可能被条件性感染，例如 if firstPathFails then log and move on to second path 等
• 如果您对“无效联系人”的处理发生变化，则不必更改解决快乐路径(在您的案例中为“有效联系人”)的测试用例。这是对 SRP 的引用.

注意事项:

• 如果测试用例中的几个相关方法需要共享设置代码，那么这可以在 @Before 方法中实现，从而减少每个 @Test 方法的大小/可存储性.
• 上述约定并不意味着单个测试方法只能有一个断言。
• 上述约定不一定适用于粗粒度测试，例如集成测试，在这种情况下可能会测试应用程序的整个部分。