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.
> 
> If a Square is a type of Rectangle than why cant a Square inherit from a Rectangle?
> 
> 
> 

The problem lies in thinking that if things are related in some way in reality, they must be related in exactly the same way after modelling. 

The most important thing in the modelling is to identify the common attributes and the common behaviours, define them in the basic class and add additional attributes in the child classes.

The problem with your example is, that's completely abstract. As long as noone knows, what you plan to use that classes for, it's hard to guess what design you should made. But if you really want to have only height, width and resize, it would be more logical to:

* define Square as base class, with `width` parameter and `resize(double factor)` resizing the width by the given factor
* define Rectangle class and the subclass of Square, because it adds another attribute, `height`, and overrides its `resize` function, which calls `super.resize` and then resizes the height by the given factor

From the programming point of view, there's nothing in Square, that Rectangle doesn't have. There's no sense of making a Square as the subclass of Rectangle.