Is it a good practice to unit test the Liskov Substitution principle's compliance?

Question

Assume a class named Sprinter:

public class Sprinter {

    protected int travelMeters;

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

    public int getTravelMeters(){
        return travelMeters;
    }
}

And a SprintGenius type inheriting Sprinter:

class SprintGenius extends Sprinter {

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

Logically, 2 unit-tests class have to be created, one for each type.

Within Sprinter unit-test, I would end up with:

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

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

Within SprintGenius unit-test, I would end up with:

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

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

In both test above, I would test the amount of traveled meters within 10 seconds.

Obviously, these both tests would be green.

However, what about the violation of Liskov Substitution principle?

Indeed, any client code should expect any sprinter to run exactly 10 meters within 9 seconds.

3 solutions (the first two solutions being signaled RULES to ALL team's developer and would have to be admit and keeped, even if not everybody well master the concept of Liskov)

1) In Sprinter class, duplicating each test but this time based on a Sprinter sprinter = new SuperGenius() and expect the 90 meters. => what should fail and this is precisely what we'd want! => prevent from violating Liskov principle.

2) In SprintGenius class, always add a similar "clone" of each test based on the base class, based on the exactly same expectations. So, if you have 2 distinct tests, we'd end up with 4 tests. 2 declaring Sprinter as a Sprinter and 2 declaring Sprinter as a SprintGenius.

3) Never inheriting from concrete class (I imagine that it was your first reaction by reading this post:)), prefer composition if it fits! So that this issue doesn't happen.

What is the best-practice to prevent from Liskov Substitution principle violation based on the fact that many many developers ignore Liskov principle and are often tempted to inherit from concrete classes instead of using another better way like composition or different inheritance hierarchy?

I don't want to be trouble by the fact that a developer inherits from my written class (without telling me..), injecting it within a shared huge list of heterogeneous Sprinter list and facing me with 'hello the weird behavior !' and hours of debug time...

I don't want of course to declare ALL my concrete classes 'final' :)

Answer 1

This is not violation of the Liskov Substitution principle's compliance. This is the bad design. Both of your classes doesn't different in behaviour, but in data. So, you should have only one class and clients should expect any sprinter to run given distance proportionally to it's speed.

So you should add speed property and have single class with concrete behaviour.

After that, you can think about creating realy extended classes with new behaviurs and think about testing.

With this speed parameter, Liskov Substitution principle should not be broken for another kinds of runners, even if they run in different speeds.

Your question is like: my class extending a person doesn't pass the test because I've changed the name of a person from "Peter" to "Robert".

This is bad example for such question. For proper example I think yes, is quit good practice to test it, but it is extremly defensive approach. Propably you can use your time given for creating tests better. Also, that test will be outdated in very short time, it's hard to add test for ever new subclass just to be sure that old behaviours works properly.

Answer 2

Unit test is about testing of the specific module and can't and shouldn't be used for something broader than that. Compliance to the Liskov Substitution Principle is a broader issue in system scope, not module scope. Moreover, it's not something to be tested in the code. It's rather a pure design issue, not linked to an implementation. I don't think LSP can be enforced by automatic tools. It should be handled during design reviews and later during code review (that should check for compliance to the design).