in general i'm not fond of the inspecting the string to determine whether the math is correct ... in an ideal world every query would have it's own unit test class and it would have a "testExplanation" method that would know exactly what structure (ie: how many sub-details) to expect from an artificially constructed query instance. the current approach of having big "explanation" test classes that validate an explanation by comparing them to the scores is a fairly big hack (and i say that as the guy that added it).
But i'm okay with the string comparisons as a "Convenience" to make it easier for us to test the explanations of the core queries (since so many of them follow very clear patterns) ... but i think we should avoid having any sort of expectation on the string for custom queries (either that they match "product of" or that they match "other:")
my main concern is purely with giving people a way to do the same kind of Explanation testing they could do before (that the root value equals the score) even if the details of their explanation don't fit any of the patterns of the existing core queries. (i'd hate for people to not even do shallow testing of their Explanations just because we don't give them a method for doing so)
- makes verifyExplanations a public method in CheckHits that anyone can call
- adds a "deep" boolean option to verifyExplanations
- adds variants of CheckHits.checkExplanations and the ExplanationAsserter to make the "deep" testing optional
- makes QueryUtils.checkExplanations use the "deep" option
- makes TestExplanations explicitly use deep testing
...at the moment, the "old" APIs default to deep==false but i'm on board with changing those to "true" if you want to (in theory it's a non-backawards compatible API change, but since it's in src/test we can probably get away with it).