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: 
> 
> And why would Square be usable anywhere you expect a rectangle?
> 
> 
> 

Because that's part of what being a subtype means (see also: Liskov substitution principle). You can do, need to be able to do this:

```cs
Square s = new Square(5);
Rect r = s;
doSomethingWith(r); // written assuming a Rect, actually calls Square methods

```

You actually do this all the time (sometimes even more implicitly) when using OOP.

> 
> and if we over-ride the SetWidth and SetHeight methods for Square than why would there be any issue?
> 
> 
> 

Because you can't sensibly override those for `Square`. Because a square *can't* "be re-sized like any rectangle". When the height of a rectangle changes, the width remains the same. But when the height of a square changes, the width must change accordingly. The issue isn't just being re-sizable, it's being re-sizable in both dimensions independently.
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.