Let’s suppose you are in a manufacturing plant.

You want to check that all cars are working properly before they are going out that door.

In order to do this, you have to focus on results when checking. In this a few results would be:

1. The car starts, and
2. The car drives

You want to check the end result of the driving.

Check the result, not whether something causing the result has occurred

What you don’t want to check is a step intermediate to or prior to the car actually driving. e.g. checking that they key has been turned, is not actually checking that the car has been started. It’s an important step that may need to be tested, but that’s a separate issue. It is possible to turn the key, and still not have the car start. You may have fell over on the final hurdle.

Test the final result, not whether something has been done or implemented which then causes (or should cause) the final result.

Another thing to note is this: what if car manufacturers changed the way that they start cars. What if now the key is not inserted but is a remote control key - which has a corresponding button in the car to start it? How would your test react to that? Because the key can’t be turned, your tests will all fail - you’d have to rewrite them again. You don’t want to do this. If you had tested whether the car goes forward, then car manufacturers could have changed the way cars are started, without requiring you to change any of your tests.

The point is to test the actual end results, rather than whether an implementation produces those end results - because it might not.