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
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
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);

  for (Class<?> eachClass : classes) {
   Method[] methods= eachClass.getDeclaredMethods();
   for (Method eachMethod : methods) {
    Annotation annotation= eachMethod.getAnnotation(annotationClass);
    if (annotation != null && ! isShadowed(eachMethod, results))
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.
Martin (Kersten)