单元测试Liskov替换原则的合规性是一种良好的实践吗？

Question

假设一个名为sprint的类：

public class Sprinter {

    protected int travelMeters;

    public void run(int seconds) {
        this.travelMeters = 9 * seconds;
    }

    public int getTravelMeters(){
        return travelMeters;
    }
}

和一个SprintGenius类型继承Sprinter：

class SprintGenius extends Sprinter {

    public void run(int seconds) {
        this.travelMeters = 10 * seconds;
    }
}

从逻辑上讲，必须创建两个单元测试类，每种类型一个。

在sprint单元测试中，我最终会得到：

@Before
public void setUp() {
  Sprinter sprinter = new Sprinter();
}

public void testSprinterShouldRun90metersWithin10Seconds() {
  sprinter.run(10);
  assertEquals(sprinter.getTraveledMeters(),90);
}

在SprintGenius单元测试中，我会得到：

@Before
public void setUp() {
  Sprinter sprinter = new SprintGenius();
}

public void testSprinterShouldRun100metersWithin10Seconds() {
  sprinter.run(10);
  assertEquals(sprinter.getTraveledMeters(),100);
}

在上面的两个测试中，我将测试10秒内的行驶量。

显然，这两种测试都是绿色的。

然而，违反利斯科夫替代原则又如何呢？

事实上，任何客户端代码都应该期望任何短跑运动员在9秒内跑10米。

3个解决方案（前两个解决方案向所有团队的开发人员发出规则信号，即使不是每个人都很好地掌握了Liskov的概念，也必须承认和保留）

1） 在sprint课程中，重复每次测试，但这次基于sprint-sprint=new SuperGenius（），预计90米=

2） 在SprintGenius类中，始终根据完全相同的期望，基于基类添加每个测试的类似“克隆”。所以，如果你有两个不同的测试，我们最终会有4个测试。2宣布Sprinter为Sprinter，2宣布Sprinter为SprintGenius。

3）永远不要继承具体类（我想这是你读这篇文章的第一反应：）），如果合适，更喜欢作文！这样这个问题就不会发生。

基于这样一个事实，即许多开发人员忽略了Liskov原则，并且经常试图从具体类继承，而不是使用另一种更好的方式，如组合或不同的继承层次结构，防止Liskov替换原则违反的最佳实践是什么？

我不想因为开发人员继承了我编写的类而麻烦（没有告诉我…），将它注入到一个共享的大量异构sprint列表中，面对我说“你好，奇怪的行为！”还有几个小时的调试时间。。。

当然，我不想将我所有的具体类都声明为“final”：

Answer 1

这并没有违反Liskov替代原则的合规性。这就是糟糕的设计。你的两个类在行为上没有不同，但在数据上有不同。所以，你应该只有一个级别，客户应该期望任何短跑运动员按照速度跑给定的距离。

因此，您应该添加速度属性，并使用具有具体行为的单个类。

之后，您可以考虑使用新的行为创建真实的扩展类，并考虑测试。

有了这个速度参数，对于其他类型的跑步者，即使他们以不同的速度跑步，也不应违反利斯科夫替代原则。

你的问题是：我的类扩展了一个人却没有通过测试，因为我把一个人的名字从“彼得”改为“罗伯特”。

这是此类问题的一个坏例子。举个恰当的例子，我认为是的，这是一个很好的实践来测试它，但这是一种极端防御的方法。也许你可以利用你的时间更好地创建测试。此外，该测试将在很短的时间内过时，很难为任何新的子类添加测试来确保旧的行为正常工作。

Answer 2

单元测试是关于特定模块的测试，不能也不应该用于比这更广泛的东西。符合Liskov替换原则是系统范围内的一个更广泛的问题，而不是模块范围。此外，它不是代码中要测试的东西。这是一个纯粹的设计问题，与实现无关。我不认为LSP可以通过自动工具强制执行。它应该在设计审查期间处理，然后在代码审查期间处理（应该检查是否符合设计）。