What he’s describing is a difference between unit testing (testing a unit in isolation, in this case a class but you can test each method if you’re masochistic enough) and integration testing where you test the class and also how it works with other classes. That’s not unit testing – you’re not testing the unit but ‘many units’.

I believe the latter is better, the trouble with it is that it is more difficult to achieve total code coverage – ie to test every part through the system. IMHO even if you unit test each and every method, you still have to test the paths through the system anyway to make sure they work together. (for example, I can test a usb plug and guarantee it works, and test a usb socket and prove it works.. and then they’ll work perfectly when assembled.. but my plug is a type A and my socket is a type B, d’oh. This design flaw should never have been there in the first place, but we can say that about any bug, which is why we test things).

Well, why don’t we just ask the man himself?

Despite the variations, there are some common elements. Firstly there
is a notion that unit tests are low-level, focusing on a small part of
the software system. Secondly unit tests are usually written these
days by the programmers themselves using their regular tools – the
only difference being the use of some sort of unit testing framework.
Thirdly unit tests are expected to be significantly faster than
other kinds of tests.

So there’s some common elements, but there are also differences. One
difference is what people consider to be a unit. Object-oriented
design tends to treat a class as the unit, procedural or functional
approaches might consider a single function as a unit. But really it’s
a situational thing – the team decides what makes sense to be a unit
for the purposes of their understanding of the system and its testing.
Although I start with the notion of the unit being a class, I often
take a bunch of closely related classes and treat them as a single
unit. Rarely I might take a subset of methods in a class as a unit.
However you define it doesn’t really matter.

…

Isolation

A more important distinction is whether the unit you’re testing should
be isolated from its collaborators. … But not all unit testers use
this isolation. Indeed when xunit testing began in the 90’s we made no
attempt to isolate unless communicating with the collaborators was
awkward …

On his blog he shows some pretty nice illustrations and explains what he means in a pretty good depth.

So when wondering what Martin Fowler means and whether or not it’s still true today, I think Martin Fowler of 2014 is the best possible source.

TDD or Test-Driven Development is where you would create a failed unit test on a method first, write the method code second, then see if the test passes. If it doesn’t, you refactor the code until it passes and then move on to your next unit test of the same method. You don’t have to use TDD to create unit tests. You can write the method first and then create unit tests for it second making sure each test passes. If you’re testing a class, you run in to integration testing because it may call out to a data layer which communicates with the database. To avoid that you’ll need to use a mocking framework so that your tests can be automated and not rely on connections outside of your application.

11 years later I would state it this way:

Unit testing in Agile is often unlike classical unit testing, because in Agile you’re usually not testing each unit in isolation. You’re testing each class and its immediate connections to its neighbors.

Note: This is still distinct from integration testing where you are testing the code and its dependencies and required services.