I’ve been grinding away on this for a couple of years now, and we’re in a good enough situation that I am going to close this iteration of the issue.

This probably wants to be revisited in every development cycle, at least for new code, so that we make sure we don’t have big testing gaps. Getting to 100% is a non-goal, though.

Commit bc3e82209d5312f7e75420d1d1abd473082349bc gets enough of JaCoCo working to be able to look into this a bit more.

At present, there are four classes with no coverage at all.

There are quite a lot of methods with no coverage, but that seems concentrated in a few (over-)complex stages such as the one for XML DSIG. Another source of this is that we have almost no tests for destroy() methods; these would be easy to add, just to make sure they don't do anything terrible.

Overall instruction coverage is 81%, which is probably higher than I expected but a fair bit lower than I'd like. It varies a lot between packages.

Branch coverage is only 68%, but a lot of that seems to be coming from the untested options in the XML DSIG stages again.

I'm going to do an initial pass over this to get rid of the biggest holes and then see where that leaves us.

A blocker to this is probably getting JaCoCo working on our code in order to be able to understand what is covered and what isn't. The general case for this is JPAR-132.

There may be some obvious gaps, but I think the situation has actually improved quite a bit. So, barring finding that large numbers of important things needs tests written for them, I think getting code coverage working will allow this to be closed.

For the record, the data file reuse issue was solved by having a resource tree structured by packages, and using ClassName-filename for individual resources within the package, so that's not a live issue now.

Progress on this probably requires getting JaCoCo or other code coverage utility working again, see JPAR-132.