Is it always 100%? Do you not really care? Are you just testing the main functionality?
For further actions, you may consider blocking this person and/or reporting abuse
Is it always 100%? Do you not really care? Are you just testing the main functionality?
For further actions, you may consider blocking this person and/or reporting abuse
SpecialBroccoli -
Ben Halpern -
ATIXAG -
talent -
Top comments (4)
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%
BUT
The cool thing is how fast the unit, functional and integration tests still are:
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?
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.