> The test.seed will cause the randomized testing to choose the same > locale/timezone/encoding/etc so that if you're hitting a bug that only shows > up with swahili or for the kiribati timezone it will reproduce reliably.
Correct. Some things will be "derived" from this property at build time (in gradle), other things will be derived from this seed at runtime. Ideally we'd pick everything at runtime but some things can only be done prior to the JVM launching (file.encoding, for example). > A) it's key to run cleanTest before running that "reproduce with" command so > that the build doesn't pass thinking the test is up to date (the reproduce > line probably ought to include this by default). This has been changed on Lucene side -- see LUCENE-9660. Perhaps it's worth porting over to Solr too. > The thread leak version fails a test called "class method" and the reproduce > string always fails with a message about junit not finding tests, because > there isn't any test named .classMethod I can explain this. JUnit reports historically didn't have any way of passing exceptions (failures) for non-test methods. This synthetic "class method" is used by the test framework to report exceptions that happened in class constructors, class-level before/after hooks and in other scopes that are outside of the regular test methods. These errors are also aggregating: a thread leak error in Solr tests is typically a result of some other, prior failure that leaves unclosed file descriptors, non-interruptible threads running in the background, etc. In an ideal world, a try-with-resources would close these resources (such as thread pools), even if an exception is thrown in the test body. Things being as they are, you get the source exception first, followed by the framework complaining about the inability to clean up test class threads (which results in completely broken test suite isolation). Dawid --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
