Is it always 100%? Do you not really care? Are you just testing the main functionality?
I have a project, which is and "old" Rails 5.1 monolith for a client ( 3 years and 10 months ago according to git log ) whose code coverage is at 98.81%
The cool thing is how fast the unit, functional and integration tests still are:
Fabulous run in 76.789949s, 18.7134 runs/s, 40.5652 assertions/s.
1437 runs, 3115 assertions, 0 failures, 0 errors, 0 skips
Coverage report generated for MiniTest. 2835 / 2869 LOC (98.81%) covered.
I love minitest.
Generally I try to stay above 80%, this is definitely an exception.
The dev.to backend is currently at 83%. Not great, but not terrible for a "startup app". There's a lot of low-hanging fruit we could test.
Ultimately test coverage isn't that important, but I do still think it's a useful metric if there are any in our industry. It's also really useful in refactoring to know what is and is not tested. That's probably the best part. It's a guiding light to give some more character to the codebase.
I think that high coverage is always a good thing, but since time is always lacking, the most important thing is that the main methods will be covered.
For example, if you have a code that is only 60% covered, but the "small" methods are not covered - that's ok, since the chances for bugs caused by these methods are lower, and even if a bug occurs - it's easier to find. What do you think?
Hey there, we see you aren't signed in. (Yes you, the reader. This is a fake comment.)
Please consider creating an account on dev.to. It literally takes a few seconds and we'd appreciate the support so much. ❤️
Plus, no fake comments when you're signed in. 🙃
My main side-project, Orchid, has been sitting around 15-20% for most of it's development life. While that number is low, I do have most of the main core API methods tested which helps me determine breaking API changes.
As of yet, it's still a very new project where I'm the only developer, and the APIs have just been changing so much that I was finding it not very worthwhile to write tests as I kept having to throw them out and write new ones. But ever since I first went public with it a couple months ago I've been working on improving the documentation and test coverage (just very slowly), and most of the new code I write now is backed with at least one test case.
Though New Year’s resolutions have never played an important role ...
We’re a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.