Robert: Thanks, I had a general idea that was the approach, but it's great to have someone point the way in detail...
Erick On Mon, Jan 17, 2011 at 5:48 AM, Robert Muir <[email protected]> wrote: > On Sun, Jan 16, 2011 at 10:09 PM, Erick Erickson > <[email protected]> wrote: > > I'm working on a patch for SOLR-445, and it's near completion. The > problem > > is that I'm getting weird test failures. TestDistributedSearch fails > *only* > > when run as part of the full "ant test", *not* when I run it either from > the > > command line (-Dtestcase=) or from within IntelliJ. > > So I assume it's some "interesting" interaction between some previous > test > > and the one in question. Before I go and try to figure it out, does > anyone > > have any wisdom to offer as to > > 1> how to go about tracking it down? > > when the test fails, you should see something like this (assuming TestG): > [junit] NOTE: all tests run in this JVM: > [junit] [TestA, TestB, TestC, TestD, TestE, TestF, TestG] > > So then hack your build.xml file, remove the junit definition for > "testpackage" and replace it with > <batchtest fork="yes" todir="${junit.output.dir}" if="testpackage"> > <fileset dir="src/test" includes="**/TestA* **/TestB* **/TestC* > **/TestD* **/TestE* **/TestF* **/TestG*"/> > </batchtest> > > now you can run just this group in a single thread with > -Dtestpackage=1 -Dtests.threadspercpu=1 > as long as the test fails, basically binary search the list to find > the offending test, by editing testpackage > e.g. you should be able to reduce it to D,E,F,G, then D,E,G, then D,G > to find out it was D that was the problem interfering with G. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
