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.
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
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.