: That's extra time, and some test methods may rely on a persistent : index across multiple test methods. The move to Junit4 was not back : compatible - test methods are not independent.
Hmmm... except they were totally independent before. I'm actually amazed that our tests pass at all -- if every method leaves stuff in the index, then i would have expected lots of tests to fail because document counts on searches don't match what they expect. I suspect that we've just gotten really lucky: within a given test class, either the methods are only looking for hte data they expect, or they are overwriting the docs added by methods that ran earlier (by reusing uniqueKey ids) : We could certainly have a little utility method that could be called, : but I'm not sure it should be called by default. but if it's not on by default then there is nothing to clean up data when another method fails which could cause other unrelated tests to fail: i can write a test method that adds docs, searches them, and then deletes them; but if something breaks the middle part, the deletes never happen and the left over data could cause a false negative in the next test. This could be an argument for more distinct Test classes containing fewer methods -- but then we're right back to re-initing the core very frequently, which seems like hte opposite of what you want. Personally, i liked knowing i had a garunteed brand new core before every test method, but if we're oing to reuse SolrCores then at the very least we should have an *empty* SolrCore before the test starts. -Hoss --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
