Unit tests check basic correctness. They don't check how things work together... because then that would be an integration test, and not a unit test.
Unit tests put pressure on the developer to abide by most of the SOLID principles, because what makes code unit testable coincides with SOLID.
Behavior tests, such as espoused by BDD using something like gherkin, are great for both specifying requirements and being able to be exercised to verify the programs behavior matches the requirements. But behavior tests are not unit tests.
Code coverage only ensure that every line of code has been exercised, and as said, nothing to do with code quality. "Untested code is buggy code", and as such code coverage only ensure the code has been exercised and does not fail a basic correctness check. (Which is better than, say, exercising rarely-to-never run error handling code in an error situation, and discovering bug in the error handling code in production.)
My biggest ire against unit tests is not regarding unit testing itself, but it is due to languages that do not support design by contract.
For those languages (which is most languages) unit tests are a means to fill in that gap. But unit tests pale in comparison to having contracts. Contracts can alleviate the need for a majority of unit tests, and much better express the intent, and unlike unit tests contracts don't "rot over time" (or as Coplien would phrase it, unit tests become muda because of the effort of maintaining them).
One of my favorite languages, D — as part of the core language — supports both contracts and unit tests, as first class language constructs.
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.
Unit tests check basic correctness. They don't check how things work together... because then that would be an integration test, and not a unit test.
Unit tests put pressure on the developer to abide by most of the SOLID principles, because what makes code unit testable coincides with SOLID.
Behavior tests, such as espoused by BDD using something like gherkin, are great for both specifying requirements and being able to be exercised to verify the programs behavior matches the requirements. But behavior tests are not unit tests.
Code coverage only ensure that every line of code has been exercised, and as said, nothing to do with code quality. "Untested code is buggy code", and as such code coverage only ensure the code has been exercised and does not fail a basic correctness check. (Which is better than, say, exercising rarely-to-never run error handling code in an error situation, and discovering bug in the error handling code in production.)
My biggest ire against unit tests is not regarding unit testing itself, but it is due to languages that do not support design by contract.
For those languages (which is most languages) unit tests are a means to fill in that gap. But unit tests pale in comparison to having contracts. Contracts can alleviate the need for a majority of unit tests, and much better express the intent, and unlike unit tests contracts don't "rot over time" (or as Coplien would phrase it, unit tests become muda because of the effort of maintaining them).
One of my favorite languages, D — as part of the core language — supports both contracts and unit tests, as first class language constructs.