我应该测试继承的方法吗？

假设我有一个从基类Employee派生的类Manager，并且该Employee有一个由Manager继承的方法getEmail（）。我是否应该测试经理的getEmail（）方法的行为实际上与员工的行为相同？

在编写这些测试时，其行为将是相同的，但是当然在将来的某个时候，有人可能会重写此方法，更改其行为，从而破坏我的应用程序。但是，从根本上测试是否存在干预代码似乎有些奇怪。

（请注意，在创建/覆盖Manager :: getEmail（）之前，测试Manager :: getEmail（）方法不会提高代码覆盖率（或其他任何代码质量指标（？））。

（如果答案是“是”，则有关如何管理基类和派生类之间共享的测试的一些信息将很有用。）

问题的等价表述：

如果派生类从基类继承方法，则如何表达（测试）是否期望继承的方法：

1. 行为与现在的基础完全相同（如果基础的行为发生了变化，则派生方法的行为不会发生变化）；
2. 始终具有与基类完全相同的方式（如果基类的行为发生变化，派生类的行为也发生变化）；要么
3. 但是，它要表现出来（您不必关心此方法的行为，因为您从不调用它）。

我在这里采用务实的方法：如果将来有人重写Manager :: getMail，那么开发人员有责任为新方法提供测试代码。

当然，这仅在Manager::getEmail确实具有与Employee::getEmail！相同的代码路径时才有效。即使未重写该方法，其行为也可能有所不同：

• Employee::getEmail可以打电话给一些受保护的虚拟getInternalEmail这是在覆盖Manager。
• Employee::getEmail可以访问某些内部状态（例如某些字段_email），这在两种实现中可能有所不同：例如，的默认实现Employee可以确保_email始终为firstname.lastname@example.com，但是Manager在分配邮件地址时更加灵活。

在这种情况下，Manager::getEmail即使方法本身的实现是相同的，错误也可能仅在中出现。在这种情况下，Manager::getEmail单独进行测试可能很有意义。

我会。

如果您在考虑“好吧，因为我没有覆盖它，所以它实际上只是在调用Employee :: getEmail（），所以我不需要测试Manager :: getEmail（）”，那么您就不是在真正测试行为Manager :: getEmail（）。

我会想到只有Manager :: getEmail（）才应该做的事情，而不管它是否被继承或重写。如果Manager :: getEmail（）的行为应返回Employee :: getMail（）返回的值，那么就是测试。如果行为是返回“ pink@unicorns.com”，那就是测试。它是通过继承实现还是重写实现都没有关系。

重要的是，如果将来发生更改，您的测试会抓住它，并且您知道某些内容已损坏或需要重新考虑。

某些人可能不同意支票中似乎存在的冗余，但我的反对意见是，您正在将行为Employee :: getMail（）和Manager :: getMail（）作为不同的方法进行测试，无论它们是否被继承或覆盖。如果将来的开发人员需要更改Manager :: getMail（）的行为，那么他们还需要更新测试。

虽然意见可能会有所不同，但我认为Digger和Heinzi给出了相反的合理理由。

不要对它进行单元测试。做功能/验收测试。

单元测试应该测试每个实现，如果您不提供新的实现，则坚持DRY原则。如果您想在这里花费一些精力，则可以增强原始的单元测试。只有重写该方法，才可以编写单元测试。

同时，功能/验收测试应确保在一天结束时所有代码都按预期进行，并希望从继承中捕获任何怪异之处。

罗伯特·马丁关于TDD的规则是：

1. 除非要通过失败的单元测试，否则不允许编写任何生产代码。
2. 您不能编写任何足以使单元测试失败的单元测试。而编译失败就是失败。
3. 您不能编写任何足以通过一项失败的单元测试的生产代码。

如果遵守这些规则，您将无法提出这个问题。如果getEmail需要测试该方法，则该方法已经过测试。

是的，您应该测试继承的方法，因为将来它们可能会被覆盖。同样，继承的方法可能会调用被覆盖的虚拟方法，这会改变非覆盖的继承方法的行为。

我测试此方法的方式是，通过创建一个抽象类来测试（可能是抽象的）基类或接口，如下所示（在C＃中使用NUnit）：

public abstract class EmployeeTests
{
    protected abstract Employee CreateInstance(string name, int age);

    [Test]
    public void GetEmail_ReturnsValidEmailAddress()
    {
        // Given
        var sut = CreateInstance("John Doe", 20);

        // When
        string email = sut.GetEmail();

        // Then
        Assert.IsTrue(Helper.IsValidEmail(email));
    }
}

然后，我有一个包含特定于的测试的类Manager，并集成了员工的测试，如下所示：

[TestFixture]
public class ManagerTests
{
    // Other tests.

    [TestFixture]
    public class ManagerEmployeeTests : EmployeeTests
    {
        protected override Employee CreateInstance(string name, int age);
        {
            return new Manager(name, age);
        }
    }
}

我之所以这样，是因为Liskov的替换原则：Employee传递Manager对象时的测试仍应通过，因为它源自Employee。因此，我只需要编写一次测试，就可以验证它们对接口或基类的所有可能实现均有效。

我是否应该测试经理的getEmail（）方法的行为实际上与员工的行为相同？

我会说不，因为我认为这将是重复测试，因此我将在Employee测试中测试一次，仅此而已。

在编写这些测试时，其行为将是相同的，但是当然在将来的某个时候，有人可能会覆盖此方法，更改其行为

如果该方法被覆盖，那么您将需要新的测试来检查被覆盖的行为。那是实现覆盖getEmail()方法的人的工作。

不，您不需要测试继承的方法。如果行为改变了，依赖这种方法的类及其测试用例将会中断Manager。

考虑以下情形：电子邮件地址被汇编为Firstname.Lastname@example.com：

class Employee{
    String firstname, lastname;
    String getEmail() { 
        return firstname + "." + lastname + "@example.com";
    }
}

您已经对此进行了单元测试，它对您的工作正常Employee。您还创建了一个类Manager：

class Manager extends Employee { /* nothing different in email generation */ }

现在，您有了一个ManagerSort可根据经理的电子邮件地址对经理进行排序的类。您认为您的电子邮件生成与中的相同Employee：

class ManagerSort {
    void sortManagers(Manager[] managerArrayToBeSorted)
        // sort based on email address omitted
    }
}

您为您编写了一个测试ManagerSort：

void testManagerSort() {
    Manager[] managers = ... // build random manager list
    ManagerSort.sortManagers(managers);

    Manager[] expected = ... // expected result
    assertEquals(expected, managers); // check the result
}

一切正常。现在有人来覆盖该getEmail()方法：

class Manager extends Employee {
    String getEmail(){
        // managers should have their lastname and firstname order changed
        return lastname + "." + firstname + "@example.com";
    }
}

现在，会发生什么？testManagerSort()由于的getEmail()会Manager被覆盖，您将失败。您将对此问题进行调查并找到原因。所有这些都无需为继承的方法编写单独的测试用例。

因此，您不需要测试继承的方法。

否则，如在Java中，你必须测试来自继承的方法Object一样toString()，equals()等在每一个类。