A unit test is an automated test that verifies a small piece of code quickly and in isolation.

Controversial attributes within this definition are the unit and isolation attributes, controversies are due to these terms being defined differently by unit testing schools.

Two unit testing schools are known as the Classical (aka Detroit) school, the teachings of this school are prevalent in the book “Test-Driven Development: By Example” by Kent Beck. The other school is the London (aka Mockist), teachings of this school are found in the book “Growing Object Oriented Software” by Steve Freeman.

𝗧𝗵𝗲 𝗟𝗼𝗻𝗱𝗼𝗻 𝘀𝗰𝗵𝗼𝗼𝗹 is based on mocking most collaborators of the system under test, therefore isolation manifests here in the form of isolating the system under test from its collaborators, while a unit is usually identified as a single class; this approach yields several advantages:

𝟭. Easy identification of areas of failure: The substitution of collaborators with test doubles eliminates them as causes of failure allowing developers to focus on the unit under test to rectify failing tests.
𝟮. Convention: As a unit is a single class, it becomes easier to organize and locate test code by creating a corresponding test class for each production class.
𝟯. Reduces object-graph complexities: As dependencies are replaced with fakes, we need not concern ourselves with the sub-dependencies of the SUT’s immediate dependencies.

𝗧𝗵𝗲 𝗖𝗹𝗮𝘀𝘀𝗶𝗰𝗮𝗹 𝘀𝗰𝗵𝗼𝗼𝗹 teachings specify that tests should revolve around units of behavior, a unit of behavior may be achieved by anything from a single method to a set of classes collaborating together, while isolation is focused around isolating tests from each other by allowing them to run independently from each other and in parallel. This approach presents a number of benefits:

𝟭. Better resilience to refactoring: The classical school keeps the use of mocking to a minimum and encourages the use of real/production collaborators instead, this means that tests are decoupled from implementation details, you no longer have to verify every method call this way if a method changes within a unit of behavior the test will still pass.
𝟮. Easily understood tests: Granularity can make it difficult to understand the bigger picture, therefore focusing on behavior leads to better-understood tests “𝘈 𝘵𝘦𝘴𝘵 𝘴𝘩𝘰𝘶𝘭𝘥 𝘵𝘦𝘭𝘭 𝘢 𝘴𝘵𝘰𝘳𝘺 𝘢𝘣𝘰𝘶𝘵 𝘵𝘩𝘦 𝘱𝘳𝘰𝘣𝘭𝘦𝘮 𝘺𝘰𝘶𝘳 𝘤𝘰𝘥𝘦 𝘩𝘦𝘭𝘱𝘴 𝘵𝘰 𝘴𝘰𝘭𝘷𝘦, 𝘢𝘯𝘥 𝘵𝘩𝘪𝘴 𝘴𝘵𝘰𝘳𝘺 𝘴𝘩𝘰𝘶𝘭𝘥 𝘣𝘦 𝘤𝘰𝘩𝘦𝘴𝘪𝘷𝘦 𝘢𝘯𝘥 𝘮𝘦𝘢𝘯𝘪𝘯𝘨𝘧𝘶𝘭 𝘵𝘰 𝘢 𝘯𝘰𝘯-𝘱𝘳𝘰𝘨𝘳𝘢𝘮𝘮𝘦𝘳” - Vladimir Khorikov

The differences between these schools spills into TDD approaches, allowing either an outside-in approach or an inside-out approach. The liberal use of mocking within the London school means that you don’t have to worry about whether the collaborator's functionality has been defined or not as it is substituted with a fake. In contrast, the Classic school's reliance on real collaborators means that your tests cannot pass until those collaborators have implementations.

Vladimir Khorikov dives into the differences between these schools in his book titled “Unit Testing”.