You just pushed your code, it was a new feature and you are proud that your code coverage is 100%. Is it safe to say since the coverage is 100% that you didn’t introduce bugs? I believe you can't.
So what is coverage?
Code coverage gives you an indication on how much lines and/or branches of your code are covered with tests. A code coverage of 70% tells you that 70% of your lines of code are touched and executed with the tests. It therefore also means that 30% isn't tested. Coverage distinguish 4 different aspects:
- Statements, are all if-paths taken?
- Branches, are all if-else paths taken?
- Functions, are all methods called and executed?
- Lines, are all line executed?
And what isn't coverage?
Code coverage isn’t a goal. It should be used as a tool to achive a goal; better tests. The coverage doesn’t reflect the code quality, it just tells you how many lines are covered by a test. A piece of code with a coverage of 100% could have as many bugs as code without the tests.
Code coverage barely reflects the quality of code. Of course, when it is well tested the develop spent some time reflecting and refactoring his / her code to be testable, but you can’t conclude that code quality is reflected in code. Business rules could be implemented wrong, or your code has some flaws in one specific browser.
Code coverage barely reflects the quality of tests. It just tells you the coverage of the tests, nothing more. Your test could be false positives and always succeed or your test tests the wrong aspects of your code.
How should I deal with the coverage?
Now you know what code coverage isn’t you probably think, so why should I use it then? Code coverage helps you and your develop team, for example it requires every developer to do minimal effort of testing.
It also helps you to be a better developer. When you write your own code and you know you have to test it you’ll notice that your code will be more clean and easy to understand to make it easier to test.