Re: extension request on org.junit.internal.MethodSorter

We recently had a similar proposal for filters, which resulted in
https://github.com/junit-team/junit/pull/647.

I'd be open to a similar solution with Sorters, as a starting point.  What
do you think?

   David Saff


On Wed, Dec 4, 2013 at 4:22 AM, Ike DuMike <[email protected]> wrote:

>
>
> Hi again David
>
> Thanks for the quick reply and good suggestion. The idea that I have
> of sorting is on three levels. I am working to support more than 10
> commercial products with varying code of bases sizes of 1000-10000
> basic tests and 1000-10000 functional and non-functional test cases
> running w/ junit. To add an annotation only, would be a major effort.
>
> What I would like to have is the following:
>
> 1) @SortWith / @FixMethodOrder on class level
> 2) System.setProperty("org.junit.internal.MethodSorter.sorter",
> "NAME_ASCENDING"); // Set from somewhere in "bootloader sequence" of
> the test classes. Effect: all Junit test classes sort test methods
> according to this setting. Classes that have the sort setting
> @SortWith or @FixMethodOrder has precedence over the property
> "org.junit.internal.MethodSorter.sorter".
> 3) -Dorg.junit.internal.MethodSorter.sorter=NAME_ASCENDING from the
> commandline (maven, gradle, ant, eclipse, intellij ...). Variant 1
> and 2 has precedence. However if not set this java -D property decide
> sorting behaviour. Value: with this option it is possible to quickly
> see test method inter dependency maturity using only a "compile"
> directive.
>
> NAME_ASCENDING is just an example. DEFAULT, JVM, NAME_ASCENDING and
> PSEUDO_RANDOM should be possible.
>
> These features I think would increase the junit user experience.
>
> Opinions on this?
>
> - ikedumike
>
> 2013/12/3, David Saff <[email protected]>:
>
> > ikedumike,
> >
> > Thanks for your long use and support!
> >
> > I think that allowing pseudo-random sorting sounds like a good extension.
> > I'd rather not use MethodSorter to do that, however, because it's limited
> > to methods in classes, and only for certain runners. For example, it
> > wouldn't allow randomizing classes within a suite. MethodSorter was
> > created merely to enable a workaround for people who found their
> > method-order changing as a result of upgrading from JDK 6 to JDK 7
> >
> > There's an existing Sorter abstraction that I think would work well for
> > this. One way to make it generally useful might be to make ParentRunner
> > recognize a @SortWith annotation that would provide a Sorter, either one
> > like this, or any other kind of Sorter.
> >
> > David Saff
> >
> >
> > On Tue, Dec 3, 2013 at 2:30 PM, <[email protected]> wrote:
> >
> >>
> >>
> >> Hi Mathew and David
> >>
> >> Having used Junit with great pleasure inside the eighth largest software
> >> organization in the world during many years I would like to ask you to
> >> add
> >> an method sorter extension to org.junit.internal.MethodSorter.
> >>
> >> It looks like:
> >>
> >> /**
> >> * Linear congruential pseudorandom number sort order, with
> >> * {@link Random#nextInt(int) } as a tiebreaker
> >> */
> >> public static Comparator<Method> PSUEDO_RANDOM = new
> >> Comparator<Method>() {
> >> public int compare(Method m1, Method m2) {
> >> final int nextInt = randomizer.nextInt(2);
> >> return nextInt == 0 ? -1 : 1;
> >> }
> >> };
> >>
> >> I can submit the full code sample with Junit test cases somewhere. It
> >> would be a great addon in junit since there are many developers that
> >> sometimes forget that it is a bad idea to create test classes where the
> >> testmethods depend on each other. TestNG has this feature. This addon
> >> would
> >> make Junit standout better in feature comparisions.
> >>
> >> Look forward to hearing from you soon.
> >>
> >> Regards
> >>
> >> Long time user and promoter of Junit
> >>
> >> - ikedumike
> >>
> >>
> >>
> >
>
>  
>