|
From: David S. <da...@sa...> - 2008-08-18 14:51:52
|
Martin,
Sorry you've waited so long for a response. Unfortunately, Java does
not guarantee any correlation between the order in which methods are
returned from a reflective query and the source-file order of the
methods. Some runtimes (including, it appears, yours), do indeed
happen to usually return methods in source-file order, but others may
not. So that your tests can run on other runtimes, it's best not to
depend on any ordering between @Before methods in the same class. If
two things must happen in a given order, you can combine them into one
method, or put one in a superclass.
David Saff
2008/4/18 Martin Kersten <Mar...@me...>:
> Dear jUnit Developers,
>
> I am using JUnit Version 4.4 and I was facing an unexpected behavior.
> Having two @Before methods in my test case I was facing an unexpected
> NullPointerException.
>
> Doing a 30sec digg I came up that JUnit 4 executes @Before and
> @BeforeClass methods of the same class in the reverse (and so
> unnatural) order. Sure the cookbook states that there is no guarantee
> about the order of execution, but this isn't such kind of necessarity.
>
> The reason for the reverse order can be found in the method
> TestCase::getAnnotatedMethods.
>
> The sequence is:
>
> foreach class of getSuperClasses(fClass)
> do collect all methods annotated with the given annotation
>
> if annotation is @Before or @BeforeClass //runsTopToButtom
> then reverse list of annotated methods.
>
> Since the whole list of methods is reversed the natural order
> (declaration order) of the methods is not preserved and anything
> would be executed bottom up even within the same class.
>
> To change this behavior and to preserve the natural order
> (you can guarantee that after imposing the change) it is simply
> to reverse the class list (getSuperClasses) rather than the
> annotated methods list:
>
> Enhanced version preserving natural order on class level:
>
> public List<Method> getAnnotatedMethods(
> Class<? extends Annotation> annotationClass) {
> List<Method> results= new ArrayList<Method>();
> List<Class<?>> classes = getSuperClasses(fClass);
>
> if(runsTopToBottom(annotationClass))
> Collection.reverse(classes);
> for (Class<?> eachClass : classes) {
> Method[] methods= eachClass.getDeclaredMethods();
> for (Method eachMethod : methods) {
> Annotation annotation= eachMethod.getAnnotation(annotationClass);
> if (annotation != null && ! isShadowed(eachMethod, results))
> results.add(eachMethod);
> }
> }
> }
>
> Please consider to preserve the natural order in the next release.
> It is not feeling correctly and I am quite certain I am not the only one
> stumbled accross.
>
> About backward compatibility: Since the library does not give
> any guarantee about the execution order of @Before and
> @BeforeClass annotated methods (beside super classes first)
> such change in execution order is just a concretion. So introducing
> this feature should only make problems if someone rely on an
> implementation detail (reverse natural order) and therefore rely
> on a non-guranteed feature.
>
> So please consider to correct this felt inconsitency.
>
>
> Cheers,
>
> Martin (Kersten)
> Email: Mar...@me...
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save $100.
> Use priority code J8TL2D2.
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Junit-devel mailing list
> Jun...@li...
> https://lists.sourceforge.net/lists/listinfo/junit-devel
>
>
|