How high is your projects code coverage?

Is it always 100%? Do you not really care? Are you just testing the main functionality?

Comments

[rhymes]

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

• I've been the sole developer for 3 years and 4 months of that
• There are too many unit and functional tests. Sometimes I get lost :D
• It's probably easier to get so much code coverage if it's a solo project
• the frontend and admin are wildly undertested and not included in the minitest coverage

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.

[Ben Halpern]

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.

[Hila Berger]

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?

[Casey Brooks]

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.