How much testing should cover

92% usually means that during tests program execution went (at least once) through 92% lines of source code.

So if your app has 1000 lines of code, 92% coverage means that during the test 920 lines of code were executed (one or more times), and 80 lines were not executed at all.

There is no magic number to answer question "what coverage % is the best".

You don't have to aim for 100%. Business logic should be tested, corner cases should be tested.

There are parts of code that do not have be tested - a good example could be getter/setter methods in Java. Testing them intentionally would provide no value, so 100% coverage is not a requirement for sure.

Coverage is, in most cases, measured in one of three ways:

• What percentage of functions are run by tests.
• What percentage of control flow paths are run by tests.
• What percentage of lines are run by tests.

The third option is the hardest to implement, but is usually overkill. Most tools implement the second option, as it's generally the most useful.

As far as how much testing should cover, that's rather subjective. The 'correct' answer is 'as much as you can cover without wasting time during testing or writing the tests', but that's not all that realistically useful.

The general idea is that you want to cover as much as possible, but you also don't want to waste lots of time covering that last 1%, and you want the tests to run fast enough that you can run them regularly (because otherwise they won't get run, which defeats the point of having the tests).

In my opinion, the coverage gives you the percentage of tests that cover your code.

It's not about the quantity but it's about quality.

It's more important to have tests that ensure the code is doing what it's supposed to do, rather than 1000 tests that shows you 100% coverage but don't mirror what it's supposed to do.