我应该对调用的基本方法进行单元测试吗？ [关闭]答案

【问题标题】：Should I unit test the base method is called? [closed]我应该对调用的基本方法进行单元测试吗？ [关闭]
【发布时间】：2014-12-09 17:02:11
【问题描述】：

我有两门课

public abstract class BaseClass
{
  public string PropertyA {get; set;}

  public virtual object CopyProperties(BaseClass other)
  {
    other.PropertyA = this.PropertyA;
  }
}

以及继承自它的类

public class ChildClass : BaseClass
{
  public string PropertyB {get; set;}

  public virtual object CopyProperties(BaseClass other)
  {
    other.PropertyB = this.PropertyB;
    base.CopyProperties(other);
  }
}

我自然对如此复杂的逻辑进行了单元测试！

我有两个测试：

Ensure_calling_CloneProperties_copies_PropertyA() Ensure_calling_CloneProperties_copies_PropertyB()

我想知道下面的测试是否也需要

Ensure_calling_CloneProperties_on_ChildClass_calls_base()

我个人的看法是，我们应该在 ChildClass 上测试 CloneProperties 的行为，我们需要验证当我们调用 clone PropertyA 和 PropertyB 时都被正确复制——我们不需要（或不想）知道这是如何实现的.然而一位同事不同意。

鉴于敏捷和 TDD 最佳实践，我是否还应该创建第三个测试？

【问题讨论】：

标签： unit-testing tdd code-coverage agile

【解决方案1】：

我同意你的意见。重要的是方法的行为，而不是其工作完成的位置。即使在交互测试方面，类与其基类之间的“交互”在系统行为方面也并不“有趣”。如果（例如）属性 A 复制最初是在基类中完成的，并且您从 Base 中删除了该功能，那么您的属性复制测试将检测到该故障，因此就回归而言，您的测试套件涵盖了重要的内容。如果将属性复制从基础移动到子级（反之亦然），则测试不会报告回归 - 并且您的系统仍会正常运行。

【讨论】：

【解决方案2】：

我还建议考虑重构代码的可能性，以便没有继承。查看这个“inheritance vs composition”线程了解更多详情。

在这种情况下，您可以注入当前的“基类功能”并确保您对 ChildClass 的测试不依赖于 BaseClass 中的代码

当您编写单元测试（在 TDD 中执行）时，您只测试该类。在您的示例中，验证 BaseClass.CopyProperties 是使用特定参数调用的事实优于检查访问 PropertyA，因为如果您更改基类，子类测试将失败 - 但它们不应该。

另一个想法可能是通过事件将BaseClass 与ChildClass 完全分离。 BaseClass 可以订阅 ChildClass 的特定事件并执行其操作，但您的测试代码现在会更加清晰，因为您所验证的只是设置了 ProperyB 并触发了事件。

【讨论】：