You’re arguing against what would classically be described as unit tests (without ever actually using that term) while arguing in favor of something else you never ascribed any name to. By your examples, that something else seems to be more on the integration test, behavior-driven test, or end-to-end test end of the spectrum. I think it’s critically important to understand that many different kinds of tests exist, they have established names, and they complement one another.

You’re right that there is tremendous value in tests that operate from (or closer to) the perspective of a user, but that’s one kind of test that really should be supplemented with other kinds of test as well. You usually cannot cover all your bases with just one type of test.

Someone told me once that behavior driven tests assert you’ve “built the right thing,” whilst unit tests assert you “built the thing right.” That’s an important distinction. Unit tests can, indeed, be brittle, but that should be expected, because they are intimately and inextricably related to the most low-level bits of your code. At that level, you can assert things that you cannot assert from several layers of abstraction up the stack. At the end of the day, it’s the only way to catch a certain class of bug that other forms of testing will never find.

A thought on the mechanic analogy — mechanics perform maintenance. Software engineers do as well, but that role is largely incidental. “Engineer” is in our title. We design. We build. Mechanics don’t do that. It’s not unfair to say that comparing software engineers to those who maintain automobiles is a less apt comparison than one to those who design them — or to those who design individual automotive parts even. I can assure you that the automotive industry doesn’t rely solely on testing of fully assembled vehicles to assert things work as they should. Before your car’s HVAC system was designed and eventually assembled, there was a radiator that was known to generate heat, a compressor that was known to compress, coolant that was known to cool, and fans that were known to blow — all within their own individual specifications. Bringing this analogy back to software, one could ask what is point of integration testing a suite of components that aren’t individually known to meet their own specifications. When that system inevitably fails, it’s anyone’s guess which component was responsible, and that’s when you start to wish you’d unit tested.