Totally untrue. Unit tests in strict sense, perhaps, but nobody writes true unit tests - there's a high chance these are actually short range functional or integration tests. Such tests are of high value.
Maybe it just depends on the context. I write embedded linux applications. One application I wrote talks to a Qualcomm modem using their QMI framework and then passes on messages to an antenna subsystem.
I wrote some library functions, which were easily unit testable, then I wrote the glue code, which I found wasn't very testable at all. I found myself having to stub out the entire QMI Framework/modem and the entire Antenna subsystem API since obviously I don't have access to those things at build time. So basically now my application/glue code is being testing in a fake vacuum that may not even reflect the real behaviors of the modem or antenna. So I waste tons of time trying to predict how the modem and antenna might behave, and test my application code accordingly.
Lastly, I end up scrapping a bunch of the tests because the actual behavior of the modem/antenna is different than I predicted and changes slightly with each update.
