“Unit tests are small tests, each one exercising a little piece of functionality. The units tested are usually individual methods, but sometimes clusters of methods or even whole objects.”
Extreme Programming Explained: Embrace Change, 2nd Edition (2004) Kent Beck
You're agreeing with me there. "each one exercising a little piece of functionality". In Beck's approach the tests are added at each step for a simple functionality addition, which then gets implemented in the project to pass the test. These days unit tests are more commonly used as "every method is a unit to be tested completely", often after the implementation is already there.
I also wonder if this is written from a statically-typed perspective. In dynamic-typing land there are so many more stupid little things that can break that the compiler would otherwise catch for you
Either that or tracing/logging/debugging, but other than specific niches like parsing (of specific bug repros) I think integration tests are generally a lot more bang for the buck.
Anyway, if you want to go down a related-but-unrelated rabbit hole, J.R. Thompson's lecture on the Space Shuttle Main Engines is a good one. You can probably watch it at higher speed to smooth out the many, many "uh"s (believe me, it's bad):
I think a more accurate version of this is: unit tests were not only per-method but also per functionality. This was often called BDD (Behavior Driven Development), e.g. Ruby's cucumber. Your intuition here is correct though.
I disagree with the "not only". The idea in xp is to write the test first. http://www.extremeprogramming.org/rules/testfirst.html You don't know how many methods/functions (if any) you're going to add to make it pass, so they're explicitly per-functionality.
There's a difference in the tests of that era though. Around the xp times, unit tests were for unit of functionality, not per-method.