OnI think that in general the code that initializes ignoreAfterMaxFailures
should take tests.iters into account?
I.e. what's the point of running a test with maxfailures=5 or failfast=true
without iters?
I looked at the code. The thing is one of these options (failfast?) is
I think a legacy
Thanks Dawid. It's not critical to change this setting and i don't want to
override it by default when running tests, only if I use tests.iters.
While we could make LTC default maxFailures to 1 if tests.iters are 1, I
don't think that it's worth it. I'll just type -Dtests.failfast=true.
Anyway,
While we could make LTC default maxFailures to 1 if tests.iters are 1, I
don't think that it's worth it. I'll just type -Dtests.failfast=true.
The default isn't without a reason -- when you run with tests.iters
with a fixed (method) seed and have multiple failures (but different
from the
Thanks Dawid!
Shai
On Sun, May 12, 2013 at 10:03 PM, Dawid Weiss
dawid.we...@cs.put.poznan.plwrote:
While we could make LTC default maxFailures to 1 if tests.iters are 1, I
don't think that it's worth it. I'll just type -Dtests.failfast=true.
The default isn't without a reason -- when
Hmm ... thought it would be a simple fix such as changing
boolean failFast = systemPropertyAsBoolean(SYSPROP_FAILFAST, false);
to
boolean failFast = systemPropertyAsBoolean(SYSPROP_FAILFAST, true);
But after I do that, tests like TestSystemPropertiesInvariantRule (and few
others) fail, on some
Can you create an issue and attach a patch? failFast is not only for
reiterations -- its primary purpose is, as far as I remember, to skip all
tests executing on this JVM after the first (or n-th in general) failure
was hit. I'd have to take a global look at this in order to constructively
tell
Oh, I didn't know that. Thought it affects only iters. In that case it may
be wrong to change the default?
Shai
On May 11, 2013 4:39 PM, Dawid Weiss dawid.we...@cs.put.poznan.pl wrote:
Can you create an issue and attach a patch? failFast is not only for
reiterations -- its primary purpose is,
I thought to make the change in LuceneTestCase.
Shai
On Fri, May 10, 2013 at 8:56 AM, Dawid Weiss
dawid.we...@cs.put.poznan.plwrote:
I don't care much. If you do though, you can specify your own override
in any of these locations?
property file=${user.home}/lucene.build.properties/
I don't have any strong opinion, to be honest so if nobody vetoes this
change, go ahead.
Dawid
On Fri, May 10, 2013 at 8:27 AM, Shai Erera ser...@gmail.com wrote:
I thought to make the change in LuceneTestCase.
Shai
On Fri, May 10, 2013 at 8:56 AM, Dawid Weiss dawid.we...@cs.put.poznan.pl
why change it?
On Fri, May 10, 2013 at 1:20 AM, Shai Erera ser...@gmail.com wrote:
Hi
Can we default tests.failfast to true? I don't know how common it is to
run with -Dtests.iters=N, not specify -Dtests.maxfailures AND wanting to
see all N tests finish.
At any rate, if someone wishes to,
Because I think it makes more sense as a default? Usually when I run with
tests.iters, I just search for a seed that fails. When I find it, I go fix
the bug and run again.
But that's just me. That's why I asked if others think it makes sense as a
default too. There is no functionality change,
I dont have any strong opinion really, i just want to mention on the side
you can also change your 'personal defaults' by editing build.properties in
your home directory too.
On Fri, May 10, 2013 at 9:27 AM, Shai Erera ser...@gmail.com wrote:
Because I think it makes more sense as a default?
Thanks for the tip. If it's just me, I won't make the change. I just find
it annoying to have to type it everytime, and think that this is probably
what you intend to achieve when running w/ tests.iters -- search for a seed
that trips the tests.
If there are no objections, I'll make the trivial
I'm still hoping for the elusive tests.beast or whatever that gives each
run a whole different seed and acts like the shellscripts that run 'ant
test -Dtestcase' over and over :)
On Fri, May 10, 2013 at 10:59 AM, Shai Erera ser...@gmail.com wrote:
Thanks for the tip. If it's just me, I won't
Me too! :)
I was hoping tests.dups would do it. Dawid promised me he will one day find
the time to do it! :)
In the meanwhile, Mike pointed me to repeatLuceneTest.py under luceneutil.
I've yet been successful to run it, but I think it's just a matter of
configuration.
Maybe if you have a
Dawid promised me he will one day find the time to do it! :)
I have it pretty high on my list of things to do in my spare time. The
problem is twofold -- I have very few spare cycles at the moment and the
problem is actually more complicated than it seems on the surface. I do
have some ideas
Hi
Can we default tests.failfast to true? I don't know how common it is to run
with -Dtests.iters=N, not specify -Dtests.maxfailures AND wanting to see
all N tests finish.
At any rate, if someone wishes to, he can always specify
-Dtests.failfast=false. It now depends what is the default behavior
I don't care much. If you do though, you can specify your own override
in any of these locations?
property file=${user.home}/lucene.build.properties/
property file=${user.home}/build.properties/
property file=${basedir}/build.properties/
property file=${common.dir}/build.properties/
Or
18 matches
Mail list logo
