Whereas the automated functional testing advocated by the OP makes a tremendous amount of sense to me intuitively.
Note that the most important programmer commodity is time. Time spent on a unit test means less time to write the program. Now, what ought to tip the scale is that later changes are easier to get right so in the long run, one should win time by writing down unit tests.
But personally, I think that there are other practices which are more effective: Static typing, assertions and automated test harnesses for the whole program. I'll choose to spend my time on these rather than unit testing.
Doing is the best way to learn most things in the software world.
Python's built-in "unittest" module is an example of that. While it's not perfect, you can quickly form good habits by using it.
And it is not limited to Python. For instance, I've written unittest-compatible classes that basically run other programs as test cases. Either way, you're forced to think about things like "how do I automatically detect that this failed?" and "is the purpose of this test clear?".
Don't just read it: Work your way through it. You need to follow the recipe to develop the discipline/knack.
Fairly quick and reasonably easy.
(Also, maybe it's just me, but a book that starts from, "Help! I just inherited a C++ project with ten years of rot and half the comments are in Norwegian! How do I even start adding tests to this without breaking it further?" seems a bit more practical than one that starts by applying unit tests to example code designed for convenient testing. It's seldom that easy.)
generally speaking if someone's angry about something, they probably don't understand it. otherwise... why not ignore it til it goes away?