Often, even outside of software, unit testing means testing a component's (unit‘s) external behavior.

If you don't accept that concept I can see how TDD and testing in general would be challenging.

I general it is most productive when building competency with a new subject to accept the author's definitions, then adjust once you have experience.

IMHO, the sizing of components is context, language, and team dependent. But it really doesn't matter TDD is just as much about helping with other problems like action bias, and is only one part of a comprehensive testing strategy.

While how you choose to define a 'unit' will impact outcomes, TDD it self isn't dependent on a firm definition.

>If you don't accept that concept

Nobody anywhere in the world disputes that unit tests should surround a unit.

>IMHO, the sizing of components is context, language, and team dependent. But it really doesn't matter

Yeah, thats the attitude that will trip you up.

The process you use to determine the borders which you will couple to your test - i.e what constitutes a "unit" to be tested is critically important and nonobvious.