[
https://issues.apache.org/jira/browse/LUCENE-6002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14166939#comment-14166939
]
Robert Muir commented on LUCENE-6002:
-------------------------------------
+1 to directly fix the monster tests. Also thanks for looking at them, as
unfortunately I think they are very rarely run.
My thoughts are: try harder to not depend on them completely for coverage of
what they test, and avoid creating monster tests whenever possible. They have
no continuous integration... I like the idea of monster tests that are doing
"real" things, but they aren't and will never be unit tests, they are not fun
to debug, and if nobody is running them then they are not helping.
We should look at each monster test and think about alternative ways to test
the scary parts, e.g. even if we can directly pass billions of things thru the
codec API instead of actually indexing billions of docs, it might be fast
enough for nightly... who knows.
A good example is TestIndexWriterMaxDocs: it does in fact have a monster test
that writes 2B docs. But this is kept very simple and only a sanity check
really, because it has tons of other non-monster actual unit tests that e.g.
change IW's limit and other tricks to test the boundary condition.
> Fix monster tests so they pass
> ------------------------------
>
> Key: LUCENE-6002
> URL: https://issues.apache.org/jira/browse/LUCENE-6002
> Project: Lucene - Core
> Issue Type: Bug
> Components: general/test
> Affects Versions: 5.0
> Environment: Linux sauron 3.13.0-36-generic #63-Ubuntu SMP Wed Sep 3
> 21:30:07 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
> java version "1.7.0_67"
> Java(TM) SE Runtime Environment (build 1.7.0_67-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)
> AMD Phenom(tm) II X3 705e, 2.5Ghz
> 12GB RAM
> Reporter: Shawn Heisey
> Assignee: Shawn Heisey
> Fix For: 5.0, Trunk
>
>
> The tests labelled @Monster are having a very hard time passing. Initially,
> there were some real failures on tests that push the 2 billion envelope, as
> well as some test bugs regarding suite timeouts and the quantity of date sent
> to sysout. [~mikemccand] committed a fix for the real failures and the
> initial sysout problems.
> Trying to move @SuppressSysoutChecks to the definition of @Monster didn't
> work. I'm also having trouble defining the suite timeouts. One test that
> says it takes about 45 minutes hit the six hour timeout that I had configured
> for the suite, and failed.
> What sort of machine should we use as a "normal" machine for deciding on
> suite timeouts? My machine is over four years old, but it's got three 2.5Ghz
> cores and 12GB of RAM. That's certainly not a completely modern machine, but
> it's not exactly slow.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
