Short answer: don't use tests.iters. Use ant beast. Long answer: It has been discussed on the list several times. tests.iters does not do what a lot of people seem to think. >From what i remember: it creates your test *class* a single time and runs stuff repeatedly... I think only (new *instance*, setup, teardown, etc). I don't even think it runs e.g. beforeclass/afterclass stuff between iterations either, but that still wouldnt make it completely safe anyway unless the whole class was recreated (a test could leave a static variable in a different state or something).
So if your test isn't a pure unit test, its probably not ready for tests.iters. Just use ant beast, it works :) On Thu, Jan 11, 2018 at 12:48 PM, Erick Erickson <[email protected]> wrote: > The recent failures in TimeRoutedAliasUpdateProcessorTest. are a result of > the changes to SOLR-11218. The initial fix is easy, but while fixing it I > saw a comment in there about cleaning up when tests.iters is specified > 1. > > The assumption was that everything would be cleaned up between runs doesn't > appear to be true for SolrCloud tests. I think one of two things is > happening: > > 1> collections (and perhaps aliases) are simply not cleaned up > > 2> there is a timing issue, we have waitForCollectionToDisappear in test > code after all. > > My question is what are the expectations? It's pretty ugly to require each > test to clean up all changes to ZooKeeper or else fail when test.iters is > set. Plus it violates the expectation that running one test doesn't affect > the other test, even if it's the same test over and over. > > So if we think it's an issue with the framework, any clues where to look > would be appreciated. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
