+1 This should be used to write tests for rolling upgrades across different versions.
On Mon, 7 Sep, 2020, 12:30 pm Dawid Weiss, <dawid.we...@gmail.com> wrote: > Just a note - such integration tests should depend on (and consume) > the output of solr/packaging (a ZIP file with fully assembled > package). Then you're really sure you're testing the final artifact. > > Dawid > > On Mon, Sep 7, 2020 at 7:51 AM David Smiley <dsmi...@apache.org> wrote: > > > > Do we have any tests that operate on a "real" Solr instance running from > "bin/solr"? Such tests could find problems with bin/solr and any classpath > matters in how Jetty operates. Solr does have JettySolrRunner which is > great but doesn't cover the aforementioned matters. > > > > We've got some really nice tests in SolrExampleTests which is a base > class and many implementations that create SolrJ clients in different > ways. I could imagine modifying this such that if a magic system property > is specified to a URL of an existing Solr instance, then the test would not > create a JettySolrRunner but instead use the configured one. This would > then be executed by the smoke tester and maybe a future Docker release > process. I have test infrastructure I wrote where I work that does this > sort of thing for our Solr plugins, and it works great. > > > > ~ David Smiley > > Apache Lucene/Solr Search Developer > > http://www.linkedin.com/in/davidwsmiley > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
