Chris: Thanks, that's the reassurance I was looking for. I'll fix this up tomorrow so it isn't order sensitive. But I didn't want to just go fix this up without some clue whether the ordering was supposed to matter (or not).
And it's just too darn late to bother. This stupid thing caused me enough frustration thinking my changes for SOLR-2971 were responsible that I didn't trust myself to make that call tonight..... Erick On Thu, Dec 15, 2011 at 10:05 PM, Chris Hostetter <[email protected]> wrote: > > : I'm consistently getting the error below when running tests, updated > : checkout of Solr 3x, no changes to the code. > : > : Note, in my case, it isn't necessary to specify the seed at all, "ant > : test -Dtestcase=TestSolrEntityProcessorUnit" fails all by itself. > > i don't see a failure, but skimming the code it looks fairly broken to > me... > > : for (Entry<String,Object> entry : row.entrySet()) { > : assertEquals(expectedDoc[i][0], entry.getKey()); > : assertEquals(expectedDoc[i][1], entry.getValue()); > : i++; > : } > > ...those lines are assuming that row.entrySet will return something that > has a predictible iteration order, but row is a Map of unknown creation > (returned by the entityProcessor) ... so unless the entityProcessor is > explicitly defined as returning something like SortedMap (which isn't > suggested anywhere in this test) the test is making a really bad > assumption. > > it looks like the "expectedDoc" data structure should be some sort of map > that is then compared to row (possibly by just doing and assertEquals on > the respective entrySets) > > > -Hoss > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
