You've fallen into the very trap of terminology the author mentions at the beginning of the article.
Testing groups of functions or classes together is still a unit test, by Wikipedia's definition at least
"unit testing is a software testing method by which individual units of source code—sets of one or more computer program modules together with associated control data, usage procedures, and operating procedures—are tested to determine whether they are fit for use" [1]
and by Michael Feather's definition
"A test is not a unit test if:
- It talks to the database
- It communicates across the network
- It touches the file system
- It can't run at the same time as any of your other unit tests
- You have to do special things to your environment (such as editing config files) to run it." [2]
Indeed, it's the inevitable result of doing TDD; the refactor step is likely to break out smaller classes/functions already covered by the existing tests. If we write new, more granular tests every time we do the refactor step, then we end up with brittle tests.
[1] https://en.wikipedia.org/wiki/Unit_testing
[2] https://www.artima.com/weblogs/viewpost.jsp?thread=126923
Edit: To clarify, I'm not talking about calling the public API over the network, I'm talking about the public methods that consumers (including your network layer) would call.
That might be where the confusion lies here.
That's not what it means, so stop believing that?
When your colleagues are talking to you, you're going to be constantly misunderstanding them if you just make up your own definitions. When I was 14 I believed @ meant about and now I no longer use @ to mean about.
It is perfectly fine to test multiple classes as a unit, in fact you probably already do so, as I would be extremely surprised if you mock your string class in all your unit tests.
https://martinfowler.com/bliki/UnitTest.html
Martin Fowler
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.
https://medium.com/@_ericelliott/i-use-the-well-known-defini...
Kent Beck
Unit tests test individual units (modules, functions, classes) in isolation from the rest of the program
Such great evidence.
Then, he goes on to, and let me emphasize this, defend the criticism that other people make that this type of test is not a unit test. (sound familiar?):
Indeed using sociable unit tests was one of the reasons we were criticized for our use of the term "unit testing". I think that the term "unit testing" is appropriate because these tests are tests of the behavior of a single unit. We write the tests assuming everything other than that unit is working correctly.
I'm not sure how thoroughly you're looking to be refuted here but I feel I can't quite do a better job.
They also overlook a large part of the value of unit tests, which is fast feedback during development time. We could push all of our tests up to the browser level, but then I lose the almost instant feedback that unit tests give me.
Sure, if your tests mock everything, and only test individual methods, then they probably are brittle and provide little value over more 'expensive' (e.g. slower) tests higher up the test pyramid.
If the tests only interact with the public APIs (e.g. the 'ports' in a ports and adapters architecture), then they are less coupled to implementation, can represent real business scenarios (instead of 'input x gives result y'), and add more value.