[
https://issues.apache.org/jira/browse/LUCENE-3489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13121105#comment-13121105
]
Uwe Schindler edited comment on LUCENE-3489 at 10/5/11 4:37 PM:
----------------------------------------------------------------
bq. Yeah, I figured that you want to keep it compact. These may be compatible
because there's nothing forbidding us to keep LuceneTestCase as a base class
(descending from Assert and providing Lucene-related infrastructure).
Yes, I just wanted to mention this.
The other stuff in LuceneTestRunner is just to work around some limitations in
JUnit's @BeforeClass: @BeforeClass does not pass the Class object to the
annotated method, and you cannot find out which child class is initialized. So
checking for annotations on the implementation class from the abstract
LuceneTestCase base class does not work.
bq. Oh, by the way – is there any particular reason for so many things to be
static (class level)? I get these are fixtures reused by tests but would people
scream if they were object-level fixtures rather than class-level fixtures?
It'd make things a bit easier... starting with the need for a single initial
seed, for example.
The reason is simple: We want those per test-class lifetime, but JUnit
allocates a new class instance for each test method. And lot's of Lucene tests
use @BeforeClass to produce indexes (random) static indexes, then used by all
test methods in a read-only way. Currently we have 3 seeds, one for class-level
stuff, one for instance stuff and a third one for the runner (according to
Mister [~rcmuir]: LUCENE-3362).
The randoms must therefore be static and initialized in @BeforeClass.
was (Author: thetaphi):
bq. Yeah, I figured that you want to keep it compact. These may be
compatible because there's nothing forbidding us to keep LuceneTestCase as a
base class (descending from Assert and providing Lucene-related infrastructure).
Yes, I just wanted to mention this.
The other stuff in LuceneTestRunner is just to work around some limitations in
JUnit's @BeforeClass: @BeforeClass does not pass the Class object to the
annotated method, and you cannot find out which child class is initialized. So
checking for annotations on the implementation class from the abstract
LuceneTestCase base class does not work.
bq. Oh, by the way – is there any particular reason for so many things to be
static (class level)? I get these are fixtures reused by tests but would people
scream if they were object-level fixtures rather than class-level fixtures?
It'd make things a bit easier... starting with the need for a single initial
seed, for example.
The reason is simple: We want those per test-class lifetime, but JUnit
allocates a new class instance for each test method. And lot's of Lucene tests
use @BeforeClass to produce indexes (random) static indexes, then used by all
test methods in a read-only way. Currently we have 3 seeds, one for class-level
stuff, one for instance stuff and a third one for the runner (not sure why).
The randoms must therefore be static and initialized in @BeforeClass.
> Refactor test classes that use assumeFalse(codec != SimpleText, Memory) to
> use new annotation and move the expensive methods to separate classes
> ------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: LUCENE-3489
> URL: https://issues.apache.org/jira/browse/LUCENE-3489
> Project: Lucene - Java
> Issue Type: Test
> Components: general/test
> Affects Versions: 4.0
> Reporter: Uwe Schindler
> Fix For: 4.0
>
>
> Folloup for LUCENE-3463.
> TODO:
> - Move test-methods that need the new @UseNoMemoryExpensiveCodec annotation
> to separate classes
> - Eliminate the assumeFalse-calls that check the current codec and disable
> the test if SimpleText or Memory is used
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
