Beyond a certain point, test coverage has diminishing returns.
You end up testing failure cases which are better addressed by good error handling. For example, inability to open a file due to file permissions can be covered in a more general way.
Erlang is one of the most effective platforms for making reliable software. It has the concept of "supervisors" which will monitor and restart code if there is a problem. This handles both known problems which are appropriately managed by the standard strategy as well as unexpected problems.
You can also use other static code analysis tools that ensure that you have dealt with every possible return code from a function.
Other things become more useful than testing, e.g. implementing observability to tell you what is happening at runtime.
Instead of more unit tests, I would prefer to have more validation checks when deploying code and in production.
A validation check for Blue/Green deployment prevents bad code from going live. A production check ensures that nothing bad is happening that affects users, e.g. if we would normally get 10 signups per hour, and we are now getting zero, then it's time to page someone. I will take that over an extra 10% code coverage any day.
Put the effort that you were going to use on code coverage into something that gets higher value.