Dear Wiki user, You have subscribed to a wiki page or wiki category on "Solr Wiki" for change notification.
The "HowToContribute" page has been changed by ErickErickson: http://wiki.apache.org/solr/HowToContribute?action=diff&rev1=78&rev2=79 Comment: Added section about frequently failing tests, prompted by SOLR-3846 }}} Where "TestXXX" is the name of the particular Junit test you want to run. + ==== Frequently failing Tests ==== + There are some tests that fail sometimes on some systems, but run on Jenkins fine. It's ''always'' a good idea to be sure you can run "ant test" successfully ''before'' you start making code changes. Or keep an un-changed version of the code around to see if your changes are really to blame. + + One of the great things about Open Source is so many people run the tests on so many different systems. Occasionally you'll be the lucky person who has the system that wins the prize by having the environment that exposes a new failure mode, see the discussion at [[https://issues.apache.org/jira/browse/SOLR-3846|SOLR-3846]] for an example. + + If you do find one of these, here's what you should do: + * First, just try running 'ant -Dtests.badapples=false test'. If the tests succeed, this is a known issue that we haven't found a solution for yet, but want to gather information about. If you have the time, ping the dev list and include your setup details. But in the case where setting this flag causes the tests to succeed, you can assume that your code changes didn't cause this error and go ahead. + * If tests continue to fail, ask on the dev list if anyone else has seen the issue. This is the case where having the un-changed code helps. If the tests fail on both the changed and un-changed versions, discuss on the dev list whether the test can be annotated as a 'badapples' test or not. + * If tests fail with your changes but not on un-altered code, well, you need to understand why. By far the most frequent reason is a bug or unintended side-effect of your code, but occasionally it's a test that needs modification. Again, the dev list is a good place to discuss this. + * Be very cautious about adding anything like @Ignore to a test. This is generally the wrong thing to do unless you get some consensus, and it'll surely generate "spirited debate". + * Of course any effort you want to make towards tracking down the reason a test fails in your particular environment is greatly appreciated! + === Creating the patch file === Check to see what files you have modified with:
