Say “No” to code coverage for these 3 reasons

Free AI web copilot to create summaries, insights and extended knowledge, download it at here

2057

Abstract

r system. Separation of units is the main principle that should be followed with unit tests. Which means that if your code is dependent on a data source you have to mock the data. If your code is dependent on other parts of your system you have to mock them as well to separate each unit. This way if you break something, you know exactly where the issue is. If you create a bug and different unit tests all over your suit are failing, it means that you did not follow the separation of your units.Code coverage may be dangerous here because not 100 % of your code is ideal to be tested by unit testing methods.Your code has sections where you are integrating various functions together, providing them with user data and creating side effects of your system. These parts of your code should be covered by integration tests depending on your needs and technology.For example, user interactions of your web application are easier to test using Selenium behaviour tests than by unit tests mocking DOM (although that is still an option). In real life, developers have a tendency to compromise separation of units just to get the code covered by tests but the value created is close to zero. It is not true that something is better than nothing because next to your code you end up also maintaining its bad tests and everything is getting more complicated to make changes.Ability to separate unit tests from integration tests closely relates to your ability to separate concerns in your code. You can still get 100 % by the combination of unit tests and integration tests reporting to your code coverage tool. However, using the right tool for the right job is more important. If you are creating a unit test and most of your work is just code to mock your environment, you may want to think about an alternative approach for this specific part of your system. If you

Options

r test covered code ends up having a production issue, you may need discussion with your development team about improving your testing strategy.Read my article about <a href="https://readmedium.com/qa-tool-stack-1a640322ce10">QA Tool Stack</a> to learn about the different methods of testing that you should be considering.<h1 id="06bd">Focus on code coverage means that you are not using TDD</h1>Test-driven development (TDD) leads you to create your tests as part of the actual development of production code. Looking at code coverage means that you have written a bunch of code and you need to catch-up with your unit tests.The benefit of TDD is not that you don’t play catch-up with your tests, but that TDD makes you think differently about the code you are currently working on. It forces you to think about what can break and what are all the use cases. If you leave your tests for later you will need much more discipline to write them properly. Tests are the best form of technical documentation if you approach them with care.Also with TDD, you are more likely to write code that is testable with better architecture, otherwise you may find yourself facing a choice whether not to test part of the system or refactor your working code just for inversion of control and testability.<h1 id="be92">In summary</h1>Make sure that you know what are the important parts of your system and that you have them well covered by your testing strategy end-to-end. Don’t focus only on unit tests because unit testing is not your only option for testing your code. If your code covered by tests ends up having production issue, don’t just fix the code but also fix your testing strategy. Good tests provide safety to your releases, lead to improvements in architecture and provide the best form of documentation. Get value from the time you invest in testing.</article></body>

Focus on code coverage means that you put quantity over quality

The obvious argument is that code coverage is just a number that says nothing about the quality of your tests. It is not different than paying developers for the number of lines of code that they create. Bad unit tests won’t really improve your system, nor will they make your releases any safer.

If you don’t follow test-driven development practices and you need to increase test coverage of your code because there are issues with frequent bugs, I recommend to prioritize rather than focus on 100 % coverage. Identify which parts of your system are most important for business and design a testing strategy that will cover these parts end-to-end with not just unit tests but also with integration tests, behaviour tests and visual tests if applicable. Features of your system that are used by most of your customers are where you should spend your time and focus on creating your internal testing process to make sure they never break. If you don’t know which those are, then find out first before doing anything else.

Read my article about making testable code to see a code with 100 % test coverage with passing unit tests and still having a bug and a number of other issues.

Focus on code coverage means that you are mixing unit tests and integration tests

There are different tests for different parts of your system. Separation of units is the main principle that should be followed with unit tests. Which means that if your code is dependent on a data source you have to mock the data. If your code is dependent on other parts of your system you have to mock them as well to separate each unit. This way if you break something, you know exactly where the issue is. If you create a bug and different unit tests all over your suit are failing, it means that you did not follow the separation of your units.

Code coverage may be dangerous here because not 100 % of your code is ideal to be tested by unit testing methods.

Your code has sections where you are integrating various functions together, providing them with user data and creating side effects of your system. These parts of your code should be covered by integration tests depending on your needs and technology.

For example, user interactions of your web application are easier to test using Selenium behaviour tests than by unit tests mocking DOM (although that is still an option). In real life, developers have a tendency to compromise separation of units just to get the code covered by tests but the value created is close to zero. It is not true that something is better than nothing because next to your code you end up also maintaining its bad tests and everything is getting more complicated to make changes.

Ability to separate unit tests from integration tests closely relates to your ability to separate concerns in your code. You can still get 100 % by the combination of unit tests and integration tests reporting to your code coverage tool. However, using the right tool for the right job is more important. If you are creating a unit test and most of your work is just code to mock your environment, you may want to think about an alternative approach for this specific part of your system. If your test covered code ends up having a production issue, you may need discussion with your development team about improving your testing strategy.

Read my article about QA Tool Stack to learn about the different methods of testing that you should be considering.

Focus on code coverage means that you are not using TDD

Test-driven development (TDD) leads you to create your tests as part of the actual development of production code. Looking at code coverage means that you have written a bunch of code and you need to catch-up with your unit tests.

The benefit of TDD is not that you don’t play catch-up with your tests, but that TDD makes you think differently about the code you are currently working on. It forces you to think about what can break and what are all the use cases. If you leave your tests for later you will need much more discipline to write them properly. Tests are the best form of technical documentation if you approach them with care.

Also with TDD, you are more likely to write code that is testable with better architecture, otherwise you may find yourself facing a choice whether not to test part of the system or refactor your working code just for inversion of control and testability.

In summary

Make sure that you know what are the important parts of your system and that you have them well covered by your testing strategy end-to-end. Don’t focus only on unit tests because unit testing is not your only option for testing your code. If your code covered by tests ends up having production issue, don’t just fix the code but also fix your testing strategy. Good tests provide safety to your releases, lead to improvements in architecture and provide the best form of documentation. Get value from the time you invest in testing.