bq. So alternatively include them by default but have a flag that will exclude them for everyday (and Lucene?) use.
+1. On Tue, Aug 14, 2018 at 5:52 AM, Jan Høydahl <[email protected]> wrote: > *think* your idea is that "ant test" would run the (probably quicker) unit > tests, but "ant precommit" would run a larger set that includes integration. > > > Not necessarily in "precommit" but perhaps "ant integrationtest" or > something. The risk is that they fall under the radar and become even more > rotten than they are already. So alternatively include them by default but > have a flag that will exclude them for everyday (and Lucene?) use. > > -- > Jan Høydahl, search solution architect > Cominvent AS - www.cominvent.com > > 14. aug. 2018 kl. 14:29 skrev Shawn Heisey <[email protected]>: > > On 8/14/2018 6:13 AM, Jan Høydahl wrote: > > Is is normally a good practice to separate unit tests from integration > tests, but with Solr we run all tests (except nightly and badapple) every > time. > I think it would help everyday development workflow if the normal "ant test" > runs would exclude integration tests (spinning up clusters etc), but rather > require those to be run before actually committing. Before we make such a > change we'd probably need to look at the code coverage without those > integration tests and add more unit tests to cover weak areas with > stubbed/mocked unit tests. > > > If I'm understanding you correctly, it sounds like a good idea. ( *think* > your idea is that "ant test" would run the (probably quicker) unit tests, > but "ant precommit" would run a larger set that includes integration. > Probably going to need a new annotation. > > I do think that integration tests that are actually expecting a timeout > should be expedited when possible. I can't say how frequently that would be > possible -- I'm not very familiar with all the inner workings of SolrCloud, > its interaction with ZK, and how the tests work. I suspect that most > integration test where we are NOT trying to cause failures with timeouts > probably will run relatively quickly, though I am sure there are some where > this is not the case. > > Thanks, > Shawn > > > --------------------------------------------------------------------- > 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]
