Test coverage 📉 🔜 📈

I'll start by sharing what test coverage is with what someone once explained to me with the following analogy:

Warm up == Testing 🧥

• The percentage of skin we cover to keep warm is the Code Coverage
• No need to cover up completely to keep out the cold and less than 100% coverage is fine
• The ability of the garment to protect us from the cold is the quality of the test
• If we wear several layers of clothing, we have duplicate tests, but sometimes it is convenient to cover ourself with more than one garment, each with its own purpose
• There are uncomfortable clothes, difficult to take off and put on. There are uncomfortable and difficult to maintain tests
• If we have to take off all our clothes and get cold to pee, we are suffering from coupled tests
• There are garments that do not last, as well as tests, which can be fragile

Extra point

• We can bundle up at home and then go outside (TDD), or we can go outside and wait until we are cold 🥶

That said, let's get down to business 🕵️‍♂️

Where we are today 🏚

Following the points mentioned above, currently our code coverage is almost non-existent:

DISCLAIMER: ⚠️ This is fake data ⚠️

=============================== Coverage summary ===============================
Statements   : 15.53% ( 2732/17590 )
Branches     : 13.17% ( 946/7179 )
Functions    : 11.85% ( 613/5169 )
Lines        : 15.72% ( 2635/16752 )
================================================================================

If we review a little more, we can see that more than half of our project has a.... ¡0%! 🚨

and if we review that 41%, we find that only 56 files have a good coverage (only 12% of our code 😱):

Why is it important?

As engineers we have to care and make sure that our code is functional for our users and that the requirements set by product are met without errors.

One thing I like to think about is that we as software engineers have to make sure that both product and user expectations are met in a realistic way, and one of the tools we have to accomplish that task under our belt is programming.

Therefore, we have to think not only about the present, but beyond that and think about our future and the future partners who will have to take over the project. That is why one of the tools that we also have at our disposal is to check that our code works, and not just now, but over time, and this is very important because it is where over time is where the benefits of the effort in writing tests can be seen.

Next steps 👣

Knowing where we are starting from, let's make a joint approach on how we can increase this lack of coverage.

Here are a few points as entry points to the discussion/brainstorming 🧠:

• Focus on case coverage* rather than code coverage
• All new code must have tests
• If any file is modified, a test case should be added for that case

case coverage*: Since this is a project that is generating revenue and there are thousands of users using it, it will be best to initially focus our energy on covering all those parts that are most important for the proper functioning of the application. The best way to do this is to talk to the stakeholders and find out which of these parts need to be covered with the highest priority.

e.g: If something stopped working, what part would you wish it didn't?

e.g: Which part would have the most impact if it were temporarily down?

Once we know what we have to reinforce first, we will have to make an analysis of the code and know if we are facing a case of detestable code or not, since it is not the same to invest hours and hours in testing something fragile (as mentioned at the beginning) than to look for alternatives and iterate little by little until we have something reliable ⭐.

Since depending on that we will have to apply E2E first and once they are working, we can perform a refactor in that part of the code with the assurance that we will not break anything or introduce regressions, and as the new code must be better than the previous and is intended to be testable we will have both E2E (happy path) and unit tests/integration that will give us the security and confidence that we were missing 🥰.

In future posts we will talk about how to analyze our code to know which parts are urgently asking for a refactor and how to approach this task.

C u in the next post! 🫶💚 (and don't forget to drink 2L of water per day!)