that is a great suggestion. Maybe the following failure of today http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-MacOSX/1927/
and in particular http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-MacOSX/1927/testReport/junit/org.apache.solr.cloud/OverseerStatusTest/testDistribSearch/ illustrates better why I think that we could be more efficient detecting issues and how this relates to your suggestion. IIUC the build took 3 hours and 11 minutes on Mac OS X virtual box and then the failure happened. If we would have the association between the file changes and the tests, then we quite probably could detect such failures much quicker and hence get it fixed much quicker. If there is no failure for such associated tests, then we could still run the whole test suite, to make sure that we have not missed any dependencies for whatever reason. I will try to get some prototype running, please apologize if I might ask stupid questions on my way. Thanks Michael Am 03.12.14 um 15:08 schrieb Alexandre Rafalovitch: > On 2 December 2014 at 18:10, Shawn Heisey <[email protected]> wrote: >> The test dependency tree for this particular class is *EXTENSIVE* and >> not very easy to track down. > How about a black box approach? Run each test individually once with a > debugging interface enabled and the code that records every class load > and every file system access. That's very similar to what JRebel does. > > Each test run is a Solr document. The loaded classes/files are > multivalued fields. Dump into standalone Solr. > > Then, when the file changes, search by it's name/location and get back > the list of tests that ever touched it. > > There are some complications due to randomised tests and also due to > changed code possibly invoking new code path, but the core idea could > probably be prototyped in a day or so to see if it has legts. > > Regards, > Alex. > > Personal: http://www.outerthoughts.com/ and @arafalov > Solr resources and newsletter: http://www.solr-start.com/ and @solrstart > Solr popularizers community: https://www.linkedin.com/groups?gid=6713853 > > --------------------------------------------------------------------- > 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]
