Readit NewsRight now I am tinkering with wails (https://github.com/wailsapp/wails) to build an app store.
You can get to 100% by having tests that run the code, but have no assertions.
You can run tests that test unimportant code just as much as super critical code. There's no differential between the two. Of course super critical code should have a number of different tests that exercise it. Its not the same as testing every path, its testing different inputs and checking that you get the right results. Also see property testing.
Chasing 100% is like any metric that becomes a goal, it perverts the metric, and moves the meaning away from the metric.
Why is that? Well, we dont really want tests at all, if only people could write perfect software first time, we wouldn't need them. Stupid people!
What we want are reliable systems! So we use feedback loops between deployed systems and code to help us discover those places where we need more tests, or a different type of testing, and then we do that.
Of course if your test coverage is 0%, thats probably bad, but 100% is a non-goal.
You'll also find that if there are no tests in a system, when you need to add them, its really hard, cos its not designed in a way that makes it testable. So maybe the TDDs will help you! You end up with a system that you have high confidence in, and also is testable.. so when you find something that doesn't work how you thought, its easy to add that test right in there.
I've always wanted to spend some more time on mutation testing, which can be used to improve test quality instead of just focussing on quantity. But I found it to be completely irrelevant in the industry so far.
https://www.puzzleship.com/