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: 
> 
> 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.
Because by LSP, creating inheritance relation between the two and overriding `setWidth` and `setHeight` to ensure square has both as same introduces confusing and non-intuitive behavior. Lets say we have a code:

```php
Rectangle r = createRectangle(); // create rectangle or square here
r.setWidth(10);
r.setHeight(20);
print(r.getWidth()); // expect to print 10
print(r.getHeight()); // expect to print 20

```

But if the method `createRectangle` returned `Square`, because it is possible thanks to `Square` inheriting from `Rectange`. Then the expectations get broken. Here, with this code, we expect setting width or height will only cause change to width or height respectively. The point of OOP is that when you work with the superclass, you have zero knowledge of any subclass under it. And if subclass changes the behavior so that it goes against expectations we have about superclass, then there is high chance that bugs will occur. And those kind of bugs are both hard to debug and fix.

One of the major ideas about OOP is that it is behavior, not data that is inherited (which is also one of the major misconceptions IMO). And if you look at square and rectangle, they have no behavior themselves that we could relate in inheritance relation.