For a flaky test like this, perhaps running it N times and asserting that
it passes ~N-1 iterations?

On 28 February 2018 at 12:00, Otto Fowler <ottobackwa...@gmail.com> wrote:

> As long as it is the pr that fails, or that someone with rights to
> re-trigger apache travis
> notices and restarts the build.
>
>
> On February 28, 2018 at 12:39:03, Gilles (gil...@harfang.homelinux.org)
> wrote:
>
> Hi.
>
> On Wed, 28 Feb 2018 08:49:42 +0200, Allon Mureinik wrote:
> > An alternative approach could be to remove the randomness from the
> > test by
> > using a predefined random seed and test the overloaded variants that
> > accept
> > a second java.util.Random argument. This will superficially reduce
> > the
> > test's coverage, but it does have a reliability advantage, IMHO (as
> > seen in
> > Otto's original email - these tests do fail occasionally).
>
> I do not seen the occasional failures as a problem if one is aware
> that they can happen due to the "random" nature of the algorithm.[1]
> Letting the seed vary (as in the application world) can reveal
> unexpected behaviour.[2]
>
> Gilles
>
> [1] See here for example:
> https://travis-ci.org/apache/commons-rng/builds/345961304
> [2] See here for example:
> https://issues.apache.org/jira/projects/MATH/issues/MATH-1361
>
> > I posted https://github.com/apache/commons-lang/pull/317 to show this
> > approach
> >
> > On Wed, Feb 28, 2018 at 12:00 AM, Gary Gregory
> > <garydgreg...@gmail.com>
> > wrote:
> >
> >> Of course... but how would test then? Shuffle N times and accept a %
> >> of
> >> non-shuffles?
> >>
> >> Gary
> >>
> >> On Tue, Feb 27, 2018, 13:18 Allon Mureinik <murei...@gmail.com>
> >> wrote:
> >>
> >> > There will still be a chance, however infinitesimal, of a failure.
> >> :-)
> >> >
> >> >
> >> > On Tue, Feb 27, 2018 at 9:02 PM, Gary Gregory
> >> <garydgreg...@gmail.com>
> >> > wrote:
> >> >
> >> > > Why not make the array 1000 items long?
> >> > >
> >> > > Gary
> >> > >
> >> > > On Tue, Feb 27, 2018 at 10:31 AM, Allon Mureinik
> >> <murei...@gmail.com>
> >> > > wrote:
> >> > >
> >> > > > All the ArrayUtilsTest#testShuffleXYZ tests take an array,
> >> shuffle
> >> it,
> >> > > and
> >> > > > assert that the result isn't equal to the original array.
> >> > > > This is usually true, but there's a small chance that the
> >> shuffled
> >> > array
> >> > > > will be equal to the original array, and thus the test will
> >> fail.
> >> This
> >> > > > chance is higher for the testShuffleBoolean case where the
> >> array
> >> > contains
> >> > > > ten elements, but only two distinct values (true and false).
> >> > > >
> >> > > > I've sent a PR to remove these problematic assertions, let's
> >> see what
> >> > the
> >> > > > maintainers think of it:
> >> > > > https://github.com/apache/commons-lang/pull/316
> >> > > >
> >> > > >
> >> > > > On Tue, Feb 27, 2018 at 6:59 PM, Otto Fowler <
> >> ottobackwa...@gmail.com>
> >> > > > wrote:
> >> > > >
> >> > > > > Note, this does pass in my personal travis:
> >> > > > >
> >> https://travis-ci.org/ottobackwards/commons-lang/builds/346806991
> >> > > > >
> >> > > > >
> >> > > > > On February 27, 2018 at 11:58:24, Otto Fowler (
> >> > ottobackwa...@gmail.com
> >> > > )
> >> > > > > wrote:
> >> > > > >
> >> > > > > My PR is currently failing for java 9 on this test. Anyone
> >> have
> >> any
> >> > > idea
> >> > > > > why?
> >> > > > >
> >> > > > > [INFO] Running org.apache.commons.lang3.ArrayUtilsTest
> >> > > > > [ERROR] Tests run: 307, Failures: 1, Errors: 0, Skipped: 0,
> >> Time
> >> > > elapsed:
> >> > > > > 0.114 s <<< FAILURE! - in
> >> org.apache.commons.lang3.ArrayUtilsTest
> >> > > > > [ERROR] testShuffleBoolean(org.apache.
> >> commons.lang3.ArrayUtilsTest)
> >> > > Time
> >> > > > > elapsed: 0.008 s <<< FAILURE!
> >> > > > > java.lang.AssertionError
> >> > > > > at
> >> > > > > org.apache.commons.lang3.ArrayUtilsTest.testShuffleBoolean(
> >> > > > > ArrayUtilsTest.java:5023)
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>



-- 
Matt Sicker <boa...@gmail.com>

Reply via email to