> if you can modify the system to make testing against it easier, that's even better.
What do you mean here? Changing your testing system, or changing the real system?
Changing the real system to add the hooks you need. Complexity often exists around waiting for events to happen (the real system doesn't need notifications, but you don't want your tests to run forever when they're failing), clocks (time.Now() is difficult to test), things like that.
Personally I am loath to add extra functionality to the real system just to make testing easier. I am massively in favor of keeping the complexity in the real system down. Adding more hooks, or increasing the interface of the real system, just to make it more testable feels wrong.
This is why I'd want test to just have a lot more 'leeway' than normal code. Essentially I want heavy hooking, introspection and reflexivity but only for tests.
The example is a little contrived, but the whole article fits on one sheet of paper and does yield a better test than mocks would.
Testing against the real system is always better than testing against a fake. That should be your first preference, and if you can modify the system to make testing against it easier, that's even better. Sometimes you can't, and if your interaction is complicated and the parts that you care about are simple, a fake can get you good confidence that your part works. Mocks just feel like writing the code again -- in your code, you write "call a function with an argument, then call another function with an argument" and in the tests you write "pass if a function is called with an argument, and again with an argument". It can be the right thing at the right time, but it's usually writing a test to make some automated linter shut up. And that's a complete waste of time.