This is surprisingly reasonable despite using unit/integration dichotomy! Though, I continue to maintain that the most important insight about testing is that there are two independent axes here:

• how much IO is done by test (none > some FS access > some IPC > some HTTP to a different machine)
• which fraction of your codebase is exercised by the test (single function without dependencies > the entire thing)

https://testing.googleblog.com/2010/12/test-sizes.html?m=1

There’s also third axes, whether we are testing a single unit of behavior, or a more complicated composite flow, but it is of the least consequences for writing tests.

EDIT: worth pointing out how the article (and I presume the book) avoids the usual confusion: it re-defines the meaning of unit! It uses neither the original meaning (unit is the test itself, unit of testing, as a encoding of a defined part of a manual testing process in a repl), nor the acquired meaning (unit as a component or module), and instead conveniently defines it as “unit of behavior”. There’s some deep truth in here about naming things!