> if you don't at least look at the running code, you don't know that it works.

Your tests run the code. You know it works. I know the article is trying to say that testing is not comprehensive enough, but my experience disagrees. But I also recognize that testing is not well understood (quite likely the least understood aspect of computer science!) — and if you don't have a good understanding you can get caught not testing the right things or not testing what you think you are. I would argue that you would be better off using your time to learn how to write great tests instead of using it to manually test your code, but to each their own.

What is more likely to happen is not understanding the customer needs well enough, leaving it impossible to write tests that align with what the software needs to do. Software development can break down very quickly here. However, manual testing does not help. You can't know what to manually test without understanding the problem either. However, as before, your job is not to deliver proven code. Your job is to solve customer problems. When you realize that, it becomes much less likely that you write tests that are not in line with the solution you need.

To be clear, I don't think we disagree very much

I've seen people only run tests and break things (because the thing they broke wasn't covered by tests), I've seen people try to fix things and not verify that their fix works, etc

Good tests are sufficient in many cases to be confident that your code still works. But in general tests don't cover a lot of fundamental behavior, and if you don't exercise that fundamental behavior in one way or another, then you don't know that your code works