Question: Whether or not a value is `null` could be checked implicitly like this:

```
assertThat(value).isEqualTo("something");

```

Or it could be checked explicitly:

```
assertThat(value).isNotNull();
assertThat(value).isEqualTo("something");

```

The latter makes the expectations a bit more clear, but it blows up the test code.

Is there a good reason to prefer the second approach over the first?

Answer: 
There are lots of good answers here; Stephen's answer in particular does a good job of illustrating why violations of the substitution principle lead to real-world conflicts between teams.

I thought I might talk briefly about the specific problem of rectangles and squares, rather than using it as a metaphor for other violations of the LSP.

There is an additional problem with square-is-a-special-kind-of-rectangle that seldom gets mentioned, and that is: *why are we stopping with squares and rectangles*? If we are willing to say that a square is a special kind of rectangle then surely we should also be willing to say:

* A square is a special kind of rhombus -- it's a rhombus with square angles.
* A rhombus is a special kind of parallelogram -- it's a parallelogram with equal sides.
* A rectangle is a special kind of parallelogram -- it's a parallelogram with square angles
* A rectangle, square and parallelogram are all a special kind of trapezoid -- they are trapezoids with two sets of parallel sides
* All of the above are special kinds of quadrilaterals
* All of the above are special kinds of planar shapes
* And so on; I could keep going for some time here.

What on earth should all of the relationships be here? Class-inheritance-based languages like C# or Java were not designed to represent these sorts of complex relationships with multiple different kinds of constraints. It's best to simply avoid the question entirely by not trying to represent all of these things as classes with subtyping relationships.
What LSP says is that anything that inherits from `Rectangle` must be a `Rectangle`. That is, it should do whatever a `Rectangle` does.

Probably the documentation for `Rectangle` is written to say that the behaviour of a `Rectangle` named `r` is as follows:

```php
r.setWidth(10);
r.setHeight(20);
print(r.getWidth());  // prints 10

```

If your Square doesn't have that same behaviour then it doesn't behave like a `Rectangle`. So LSP says it must not inherit from `Rectangle`. The language can't enforce this rule, because it can't stop you doing something wrong in a method override, but that doesn't mean "it's OK because the language lets me override the methods" is a convincing argument for doing it!

Now, it would be *possible* to write the documentation for `Rectangle` in such a way that it doesn't imply that the above code prints 10, in which case maybe your `Square` could be a `Rectangle`. You might see documentation that says something like, "this does X. Furthermore, the implementation in this class does Y". If so then you have a good case for extracting an interface from the class, and distinguishing between what the interface guarantees, and what the class guarantees in addition to that. But when people say "a mutable square is not a mutable rectangle, whereas an immutable square is an immutable rectangle", they're basically assuming that the above is indeed part of the reasonable definition of a mutable rectangle.