It varies. Our library-level code tends to be very well unit- and integration- tested. At the application layer, there's a bit of a split between "q&a" and "careers". The careers code, again, has a high degree of testing. The q&a code.... well, we have some tests, but it would be incorrect to say that we live in a pure TDD world. Simply, in our particular case, we've felt that there isn't a huge overlap between the "errors this would help us catch" and "the errors that actually cause problems". We have no problem whatsoever spending time to solve real problems - and if this was something that was hurting us we would go fix that, but to date: this simply has not been an issue. We try to avoid imagineering (which is not to dismiss the value of testing, by an means).
Additionally, note that the q&a code has some pretty ambitious performance targets. To achieve that, we actively avoid unnecessary abstractions. Necessary abstractions are fine and encouraged. But you wouldn't add an
IAbstractFactoryBuilderFactoryProviderService without facing the mocking wrath of the team (or is that "wrathful mocking"?). We care about the design of the code, but we don't add layers that don't solve an actual problem that we genuinely have. I don't say this as a "here's why we don't go crazy with TDD" - but it is tangentially related. If we wanted to go fully TDD in the app-code, we could - but there would be quite a lot of change required. Which, to be fair, is also not something we object to - we tend to be pretty happy (and able) to perform large refactors on the code.
If a developer feels that a particular area needs more tests: that's fine. Go do that. But there isn't a hard rule about "100% code coverage" or anything. Actually, if we ever got 100% code-coverage, I would start to suspect that I was in a Philip K. Dick-esque fantasy world in my own fevered imagination. The team trusts the team to make sensible decisions about what needs rigorous testing.
Stack Exchange is my role-model for application development
I genuinely don't claim any of this is a "here's how you should work"; the strategy we use is based on a full understanding of the problems we face daily (and importantly, the problems that we don't face daily). Every team, and every project, is different. I don't think the above would fly in finance, medical, education, or military systems (although I suspect that it happens more often than people might think in all four cases).