I think we have false perception of the cost/time tradeoff of unit test vs integration test.
If we only look at time to write the test in the first place, and how fast it takes to execute, unit tests come ahead integration for sure.
But you have to add a lot more unit tests to cover the same component, compared to integration tests. Also, each refactor needs to alter a couple of unit tests as well - while integration tests operate on the outer interface, less likely to change, thus less likely to need modifications when refactoring.
Add to that my subjective that most hard bugs happen due to some mismatch on boundaries between systems, which is less captured by unit tests.
Not saying we shouldn't unit test, but its role is overrated vs integration tests.
About coverage
I agree that 100% coverage is just for the show. In my experience, you should aim for 60-70% coverage. To go above that, you have to add meaningless tests on getters and such.
But coverage in itself is meaningless. There was a story where after a big company mandate, coverage grew nicely. Until they found out devs copy-pasting dummy 100% tested classes just to push up the ratio of covered code.
I would advise this: you know which parts of the code are quirky. Use coverage as an assistant to ensure you have covered those well, for your own sake. Don't care about global coverage numbers.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
About unit test vs integration
I think we have false perception of the cost/time tradeoff of unit test vs integration test.
If we only look at time to write the test in the first place, and how fast it takes to execute, unit tests come ahead integration for sure.
But you have to add a lot more unit tests to cover the same component, compared to integration tests. Also, each refactor needs to alter a couple of unit tests as well - while integration tests operate on the outer interface, less likely to change, thus less likely to need modifications when refactoring.
Add to that my subjective that most hard bugs happen due to some mismatch on boundaries between systems, which is less captured by unit tests.
Not saying we shouldn't unit test, but its role is overrated vs integration tests.
About coverage
I agree that 100% coverage is just for the show. In my experience, you should aim for 60-70% coverage. To go above that, you have to add meaningless tests on getters and such.
But coverage in itself is meaningless. There was a story where after a big company mandate, coverage grew nicely. Until they found out devs copy-pasting dummy 100% tested classes just to push up the ratio of covered code.
I would advise this: you know which parts of the code are quirky. Use coverage as an assistant to ensure you have covered those well, for your own sake. Don't care about global coverage numbers.