Code coverage will tell you how much you covered your methods/function, but it does not mean how "well" you tested. To answer your first question, it does not mean very much for me alone. 70% is still a very good sign.
When I have this same conversation we have, but with my collegues, I always answer: unit testing methods or functions alone is not enough. This reminds me of another Dev.to post in which the author raise an interesting point in the sense that unit test will make it hard to reproduce a "real life" context, because you are monkey patching all around but not taking real scenarios that could potentially impact your methods or function. So the answer to your second question would be yes, but not only.
The best thing to do for a 20+ year old product, is to monitor. Monitor everything. But only if the time allow you to. If it has not been planned in your priorities, do not take the risk to loose some time for this.
Monitoring will make the moment you are trying to convince your lead dev/PO that unit testing is healthy easier.
To do so, install the proper library, and go piece by piece. Fixing issues has been proven to be an easy and gradually step for me to introduce unit tests. And check the code coverage before and after a PR. You will find some great improvements only with unit tests.
Then, within a month or so, your lead dev would already notice your are including those tests and will ask you why. Then pop up those statistics, the time you took, and the time you will not spend if the fixed case comes again.
Finally, you can say that you should start being confident over what you delivrer, and unit tests are perfect for this task.
Meenakshi Agarwal, 10+ years in IT. Managing TechBeamers.com, creating insightful tutorials, quizzes, and exercises in C, Python, Java, SQL, Selenium, and C-Sharp.
Thanks for replying with such great details and clarity. I do agree to work on unit tests piece by piece, improve, and demonstrate the results to other stakeholders to get them convinced. Your ideas are indeed constructive and helpful.
I see many make the mistake of asking managers and product owners permission to do things they deem neccassary for the health and stability of the project. I never ask if I can write tests or do TDD, its just part of my estimate of entire task. Just like a doctor won't ask you, "Do you mind if I wash my hands before the surgery? Its going to take an extra 15 minutes."
One thing to keep in mind when we talk "unit" tests. There is wide range of ideas of what "unit" means. Really when we talk about testing, we want to have a suit of tests that I can run on my local machine that at most will take a minute or less to run. I use TDD and this is important because of the red, green , refactor loop. If the tests for the part of the code I work on take longer then a few seconds, that slows me down. I need quick feedback loops so I can make progress. The longer the tests take to run, the longer my red, green, refactor loops get, the less work I can get done. Or worse, people stop running the tests.
Your automated suite of functional tests may be fitting these needs if any developer can run them on any machine at any time and at most takes a couple minutes to run all the tests. If this is not the case then you may want to look into using "unit" tests.
This is really good point Michael! Testing and documentation are both crucial parts of software development, not just something you add if there's time. Unfortunately many managers only measure things in short-term and either don't care or don't know how to measure the long tail of work that bad code and documentation cause.
Sometimes lack of tests makes it super slow to add new code because you're worried it will break things. Sometimes lack of documentation wastes days of developer time that could have been avoided by minutes or hours of work up ahead.
Code coverage will tell you how much you covered your methods/function, but it does not mean how "well" you tested. To answer your first question, it does not mean very much for me alone. 70% is still a very good sign.
When I have this same conversation we have, but with my collegues, I always answer: unit testing methods or functions alone is not enough. This reminds me of another Dev.to post in which the author raise an interesting point in the sense that unit test will make it hard to reproduce a "real life" context, because you are monkey patching all around but not taking real scenarios that could potentially impact your methods or function. So the answer to your second question would be yes, but not only.
The best thing to do for a 20+ year old product, is to monitor. Monitor everything. But only if the time allow you to. If it has not been planned in your priorities, do not take the risk to loose some time for this.
Monitoring will make the moment you are trying to convince your lead dev/PO that unit testing is healthy easier.
To do so, install the proper library, and go piece by piece. Fixing issues has been proven to be an easy and gradually step for me to introduce unit tests. And check the code coverage before and after a PR. You will find some great improvements only with unit tests.
Then, within a month or so, your lead dev would already notice your are including those tests and will ask you why. Then pop up those statistics, the time you took, and the time you will not spend if the fixed case comes again.
Finally, you can say that you should start being confident over what you delivrer, and unit tests are perfect for this task.
Hope it helps :)
Thanks for replying with such great details and clarity. I do agree to work on unit tests piece by piece, improve, and demonstrate the results to other stakeholders to get them convinced. Your ideas are indeed constructive and helpful.
I see many make the mistake of asking managers and product owners permission to do things they deem neccassary for the health and stability of the project. I never ask if I can write tests or do TDD, its just part of my estimate of entire task. Just like a doctor won't ask you, "Do you mind if I wash my hands before the surgery? Its going to take an extra 15 minutes."
One thing to keep in mind when we talk "unit" tests. There is wide range of ideas of what "unit" means. Really when we talk about testing, we want to have a suit of tests that I can run on my local machine that at most will take a minute or less to run. I use TDD and this is important because of the red, green , refactor loop. If the tests for the part of the code I work on take longer then a few seconds, that slows me down. I need quick feedback loops so I can make progress. The longer the tests take to run, the longer my red, green, refactor loops get, the less work I can get done. Or worse, people stop running the tests.
Your automated suite of functional tests may be fitting these needs if any developer can run them on any machine at any time and at most takes a couple minutes to run all the tests. If this is not the case then you may want to look into using "unit" tests.
This is really good point Michael! Testing and documentation are both crucial parts of software development, not just something you add if there's time. Unfortunately many managers only measure things in short-term and either don't care or don't know how to measure the long tail of work that bad code and documentation cause.
Sometimes lack of tests makes it super slow to add new code because you're worried it will break things. Sometimes lack of documentation wastes days of developer time that could have been avoided by minutes or hours of work up ahead.
Speaking the truth here, I cannot count how many example I have of untested code that produce side effects over time...