: (I had left the comment in question)
: I think a test shouldn't have to explicitly clean up after itself, except
: perhaps intra-method as-needed; test-infrastructure should do the class
: (test suite).
All test code should always be expected to clean up their messes at
whatever "ending" stage corrisponds with the stage where the mess was
made.
how the mess is cleaned up, and wether infrastructure/scaffolding code
helps do that dpeends on the specifics of the infrastucture/scaffolding in
question -- if you make a mess in a test method that the general purpose
infrastructure doesn't expect, then the burden is on you
to add the level of infrastructure (either in your specific test class, or
in a new abstract base class depending on how you think it might be
re-usable) to do so.
In the abstract: Assume AbstractParentTest class that creates some
"parentMess" in @BeforeClass, and deletes "parentMess" in an
@AfterClass....
1) if you want all of your tests methods to have access to a
shiny new/unique instance of "childMess" in every test method, then burden
is on you to create/destroy childMess in your own @Before and @After
methods
2) If you want test methods that are going to mutate "parentMess" then the
burden is on you to ensure (ideally via @After methods that "do the right
thing" even if the test method fails) that "parentMess" is correctly reset
so that all the test methods depending on "parentMess" can run in any
order (or run multiple times in a single instance) ... either that, or you
shouldn't use AbstractParentTest -- you should create/destroy
a "parentMess" instance yourself in your @Before & @After methods
Concretely...
: > 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.
...these are vague statements ("everything", "SolrCloud tests", "not
cleaned up") and not being intimately familiar with the test class in
question it's not clear exactly is happening or what expectations various
people have -- BUT -- assuming this is in regards to
SolrCloudTestCase, that base class has very explicit docs about
how it's intended to be used: you are expected to configure & init a
MiniSolrCloudCluster instance in an @BeforeClass method -- it has helper
code for this -- and that cluster lives for the lifespan of the class at
which point an @AfterClass in SolrCloudTestCase will ensure it gets torn
down.
Tests which subclass SolrCloudTestCase should be initializing the cluster
only in @BeforeClass. Most tests should only be creating collections in
@BeforeClass -- allthough you are certainly free to do things like
create/destroy collections on a per test method basis in @Before/@After
methods if you have a need for that sort of thing.
If that's not the lifecycle you want -- if you want a lifecycle where ever
individual test method gets it's own pristine new MiniSolrCloudCluster
instance w/o any pre-existing collections, then you shouldn't use
SolrCloudTestCase -- you should just create/destroy
unique MiniSolrCloudCluster instances in your own @Before/@After methods.
Bottom Line: there is no one size fits all test scaffolding -- not when we
have some tests classes where we want to create a collection once, fill it
with lots of docs, and then re-use it in 100s of test methods, but other
classes want to test the very operation of creating/deleting collections.
Use the tools that make sense for the test you're writting.
-Hoss
http://www.lucidworks.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
