"What does it really mean that 70% of the code is covered by unit tests?"
It means that 70% of the code guarantees basic correctness. Unit testing is good for languages that do not provide contract support. For those languages that do provide contract support (Eiffel, D, Spec#, Sing#, C++20) unit tests fill the small gap that are not covered by contracts.
It does not mean that any of that code will work properly together -- for that you need other kinds of testing, such as one-or-more of integration tests, acceptance tests, system tests, performance tests, security tests, fuzzing tests, stress tests, specifications expressed in a DSL that can be executed as part of a BDD test suite, et cetera.
Sure and that is exactly the point. Unit tests and some other forms of tests will only cover so much and if you have a perfect application based on all available standards and tests modalities out there, its quality is measured by how the end-user will perceive it.
A quality product could be defined by many perceptions. For a team lead it could be 70% of code coverage, for a manager it could be 5% risk of deployment, for a CIO it could be how much revenue it generates and for the user, it could mean anything even if the color of the link is wrong.
So if you consider risk as a baseline for quality, regardless of any other perception, that is a message that can be passed among any other portions of the organization in different forms and even then, risk can have different ways of being measured.
The idea of the post is to bring some light that the way that we measure software quality today can't be translated to the industrial world in the same way because you wouldn't be able to measure 6 Sigma for software, for example, but you could measure risk.
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.
"What does it really mean that 70% of the code is covered by unit tests?"
It means that 70% of the code guarantees basic correctness. Unit testing is good for languages that do not provide contract support. For those languages that do provide contract support (Eiffel, D, Spec#, Sing#, C++20) unit tests fill the small gap that are not covered by contracts.
It does not mean that any of that code will work properly together -- for that you need other kinds of testing, such as one-or-more of integration tests, acceptance tests, system tests, performance tests, security tests, fuzzing tests, stress tests, specifications expressed in a DSL that can be executed as part of a BDD test suite, et cetera.
Sure and that is exactly the point. Unit tests and some other forms of tests will only cover so much and if you have a perfect application based on all available standards and tests modalities out there, its quality is measured by how the end-user will perceive it.
A quality product could be defined by many perceptions. For a team lead it could be 70% of code coverage, for a manager it could be 5% risk of deployment, for a CIO it could be how much revenue it generates and for the user, it could mean anything even if the color of the link is wrong.
So if you consider risk as a baseline for quality, regardless of any other perception, that is a message that can be passed among any other portions of the organization in different forms and even then, risk can have different ways of being measured.
The idea of the post is to bring some light that the way that we measure software quality today can't be translated to the industrial world in the same way because you wouldn't be able to measure 6 Sigma for software, for example, but you could measure risk.