re: Add unit tests on a project already in progress VIEW POST


What is the significance of unit testing or automating it if someone has a fully automated functional test suite with 70%-80% test coverage (we keep adding new cases with the growing feature set, automate defect fixes as well) and 60%-70% code coverage? Would unit testing make any difference in such a situation? The product is a software development kit (SDK) and almost 20+ year old but still flourishing. And if yes, then how to convince the Product owners to allow for it.


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...


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.

I agree I have seen so many tests that simply cheats, they are testing nothing really but trivialities.

code of conduct - report abuse