[ 
https://issues.apache.org/jira/browse/LUCENE-4630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13532541#comment-13532541
 ] 

Hoss Man commented on LUCENE-4630:
----------------------------------


bq. In my opinion, we should really warn users also on Solr startup, if they 
have...

This is a great idea -- i've spun off LUCENE-4631 to track that since it's kind 
of broader then if/how to allow people to run tests even under suspicious 
circumstances (but whatever we add there can probably be leveraged here)

bq. Why does it need to be a system property, Hoss?

No reason ... it was just the first thing i thought of that seemed really 
generic. Anyplace we might normally write...

{code}
boolean someBoolean = ...something interesting...;
if (someBoolean) {
  throw new AssumptionViolatedException("...why your system is suspicious...")
}
{code}

...could be replaced with...

{code}
boolean someBoolean = ...something interesting...;
if (someBoolean || Boolean.getBoolean("tests.suspicious.shit")) {
  throw new AssumptionViolatedException("...why your system is suspicious...")
}
{code}

...of the top of my head, i wasn't sure if an annotation would be as easy to 
use (particularly when you might mix and match with other test groups)

bq. @SuspiciousJ9Shit

My suggestion was to try and keep it _reaallly_ generic ... so that with one 
"option" active you say "i'm a developer who is asking for trouble, try 
everything even if you think it's not valid on my system.  Making people know 
that their particular os/jvm/filesystem/jvm-opt-combos are suspicious therefore 
they need to explicitly ask for test group X and test group Y test group Z 
seems like it would make it overly hard for people to try everything.

Perhaps the ideal case would be specific annotations like you describe, which 
could be used as test groups for people who want to go out of their way to test 
specific suspicious stuff (ie: "there is a new J9 JVM, does it still have these 
problems?") but then have a feature in the runner that by default those groups 
are skipped with a clear AssumptionViolatedException("...what is suspicious 
about your setup ...") but if you set "-Dtest.suspicious.shit=true" then 
instead the runner will run those tests anyway, but wrap any 
failures/exceptions it gets in another "FailureUnderSuspiciousCircumstances" 
exception whose getMessage() would contain info about what assumption would 
have normally prevented that test from if you hadn't gone out of your way to 
run it.

what do you think?


                
> add a system property to allow testing of suspicious stuff
> ----------------------------------------------------------
>
>                 Key: LUCENE-4630
>                 URL: https://issues.apache.org/jira/browse/LUCENE-4630
>             Project: Lucene - Core
>          Issue Type: Bug
>            Reporter: Hoss Man
>            Priority: Blocker
>             Fix For: 4.1
>
>
> there are times when people want to add assumptions in test to prevent 
> confusing/false failures in certain situations (eg: known bugs in JVM X, 
> known incompatibilities between lucene feature Z and filesystem Y, etc...)
> By default we want these situations to be "skiped" in tests with clear 
> messages so that it's clear to end users trying out releases that these tests 
> can't be run for specific sitautions.
> But at the same time we need a way for developers to be able to try running 
> these tests anyway so we know if/when the underliyng problem is resolved.
> i propose we add a "tests.suspicious.shit" system property, which defaults to 
> "false" in the javacode, but can be set at runtime to "true"
> assumptions about things like incompatibilities with OSs, JVM vendors, JVM 
> versions, filesystems, etc.. can all be dependent on this system propery.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to