c# - 您是否应该对共享相同私有(private)实现的单独方法进行重复单元测试？

Question

我正在为我们的大型企业应用程序构建一个业务层，目前我们的单元测试不到 500 个。场景是我们有两个 public 方法，public AddT(T) 和 public UpdateT(T) 都对 private AddOrUpdateT(T) 因为很多核心逻辑在两者之间是相同的，但不是全部；他们是不同的。

因为它们是独立的公共(public) API(不考虑私有(private)实现)，所以我为每个 API 编写了单元测试，即使它们是相同的。这可能看起来像

[TestMethod]
public void AddT_HasBehaviorA() 
{
}

[TestMethod]
public void UpdateT_HasBehaviorA() 
{ 
}

目前，对于这个特定的业务对象，大约有 30 个用于添加的单元测试和 40 个用于更新的单元测试，其中 30 个更新测试与添加测试相同。

这是正常的，还是我应该将常见行为抽象到一个单独进行单元测试的公共(public)帮助程序类中，并且这两个 API 只使用该帮助程序类而不是具有实现的私有(private)方法？

什么是这些情况下的最佳做法？

Answer 1

首先，了解为什么要通过单元测试覆盖这些方法很重要，因为这会影响答案。只有您和您的团队知道这一点，但如果我们假设单元测试的至少部分动机是获得可信赖的回归测试套件，那么您应该测试可观察的行为 被测系统 (SUT)。

换句话说，单元测试应该是黑盒测试。测试不应该知道 SUT 的实现细节。因此，您可以从中得出一个天真的结论是，如果您有重复的行为，那么您也应该有重复的测试代码。

但是，您的系统变得越复杂，它越依赖于常见的行为和策略，就越难实现此测试策略。这是因为您将通过系统对可能的方式进行组合爆炸。 J.B. Rainsberger explains it better than I do .

更好的替代方法通常是聆听您的测试(GOOS 推广的概念)。在这种情况下，将常见行为提取到公共(public)方法中听起来很有值(value)。然而，这本身并不能解决组合爆炸的问题。虽然您现在可以单独测试常见行为，但您还需要证明两个原始方法(Add 和Update)使用新的公共(public)方法(而不是，例如，一些复制和粘贴的代码)。

最好的方法是使用新策略组合方法:

public class Host<T>
{
    private readonly IHelper<T> helper;

    public Host(IHelper<T> helper)
    {
        this.helper = helper;
    }

    public void Add(T item)
    {
        // Do something
        this.helper.AddOrUpdate(item);
        // Do something else
    }

    public void Update(T item)
    {
        // Do something
        this.helper.AddOrUpdate(item);
        // Do something else
    }
}

(显然，您需要为类型和方法提供更好的名称。)

这使您能够使用 Behaviour Verification 证明Add 和Update 方法正确使用了AddOrUpdate 方法:

[TestMethod]
public void AddT_HasBehaviorA() 
{
    var mock = new Mock<IHelper<object>>();
    var sut = new Host<object>(mock.Object);
    var item = new object();

    sut.Add(item);

    mock.Verify(h => h.AddOrUpdate(item));
}

[TestMethod]
public void UpdateT_HasBehaviorA() 
{ 
    var mock = new Mock<IHelper<object>>();
    var sut = new Host<object>(mock.Object);
    var item = new object();

    sut.Update(item);

    mock.Verify(h => h.AddOrUpdate(item));
}