>Let's get specific, so that our terms can be better defined, and we can make sure that we're not just arguing about definitions of terms. Instead of "unit", let's say "C++ class". Now: By my definitions, my unit test should test the behavior of the public API of that class, not the private implementation. So the API is an implementation detail of the project, but not of the class. I will agree that the unit test definitely couples to the interface of the class. Done right, though, it doesn't couple to the implementation of the class.

In almost all cases (the exception being if the class is the core of a library's externally facing API), the class itself is an implementation detail.

>A bigger source of technical debt than the bugs you can't find that are buried in the implementation of some class?

Yes, obviously. Bugs are not technical debt.

>And good tests mean that those bugs don't make it very far before getting exposed.

And integration tests are generally better at finding said bugs than unit tests since they test more realistically.

>A bigger source of technical debt than that API that you don't know how to use, and so you call it wrong?

Is again, a bug - not technical debt.

Unit tests are horrible for this since they require you to mock APIs that you're calling. The test which mocks the API wrongly won't catch that bug but the integration test that uses the real API will.

>Tests can actually serve as documentation for how to use an API.

Yes they can. Integration tests can double as a specification for an entire application which is even better than a documentation for a (potentially) badly architected API.