Me: By mandating code coverage pct. (very high ones) and integration test coverage pct. you are building an ever growing Rube Goldberg machine that you will end up spending most of your time fixing rather than working on the actual product.

Them: (Staring and whispering in the background). Wow, you must be stupid. This is how you created quality software.

...time passes and now most time is sucked into figuring out why all branches have failing integration tests all the time.

Me: I told you so. I've seen it multiple times. How about doing it differently?

Them: (staring and whispering in background). You are stupid. This is exactly how quality software is built. We know what we are doing. You must like waterfall.

I'm sorry to tell you that they're right.
That is how software quality can be guaranteed.
And this fact is priceless, since in IT there is almost no chance for a guarantee.

On the other hand it is important that 100% code coverage was reached by using real unit-tests where non of this tests has a fixed dependency on another unit/class!

@TylerDDevRant , don't be sorry. You are certainly entitled to your opinion just as they are. I just happen to disagree with you completely. Test coverage in no way equates with or guarantees quality. I can write crappy code and meaningless tests and end up with something that doesn't work and nobody wants. Tests are smoke alarms. They tell you if something that you don't want to change has changed. That's all ( not to diminish the importance of knowing that for important things). We have unit tests that count the number of system colors in Windows. We have integration tests that fail sporadically because they try to measure performance against arbitrary constants but run in and uncontrolled environment. Tests are only of value if they test something of value and they never guarantee a level of quality in what is being tested.

I agree with you.

Unit-testing without using TDD is only half the share.
This constellation leads to the overkill you described.

But any developer with experience - and by experience I mean the number of "Boss: What have you fucked up. Nothing works anymore. Dev: Sorry. I have no idea. I will spend a bunch of hours/your money to find the source of chaos I accidentally released" situations - some day will come to the conclusion that TDD is a very attractive way to build the code.

^^

I agree with the general pointlessness of unit tests. So what if you function returns "Bananas" every time you call it.

Automated UAT. Now that's where it's at.