Skip to main content
brian_thomas2
Adobe Employee
Adobe Employee
July 15, 2010
Answered

Ordering Behavior in Test SubClasses

  • July 15, 2010
  • 1 reply
  • 1801 views

The ordering behavior between inherited test classes seems to have changed between FlexUnit 4 and 4.1 beta 2.

Here is the order my test methods are running in:

SubClass [After(order=9)]

SubClass [After(order=10)]

BaseClass [After(order=1)]

4.0 did this:

BaseClass [After(order=1)]

SubClass [After(order=9)]

SubClass [After(order=10)]

I think the old behavior is correct... maybe a bug here?

Thanks,

Brian

This topic has been closed for replies.
Correct answer mlabriola

Thanks Mike - that does clear things up. I am looking for the old behavior where order is given priority over hierarchy.

However, I don't think that the fix is as simple as passing the old OrderArgumentSorter to Request.sortWith(). It looks like BlockFlexUnit4ClassRunner's withBefores() and withAfters() methods are hard-coded to use OrderArgumentPlusInheritanceSorter and only call the custom sorter in the case that they're in the same class. Even with my own custom sorter, I'll only get calls to compare() for methods on the same level of inheritance.

Brian


Yes, you are correct and I also discovered that this morning. I have a potential fix I am looking at now and will push it up to my branch today.

I can get you an early build to test against and will absolutely ensure this is in before RC1

Mike

1 reply

Participating Frequently
July 15, 2010

It is a result of a common feature request that Before and After have hierarchical lineage used as well as order.

I could provide a flag to turn it off or you could specify the sorter.

Let me know what you would like,

Mike

brian_thomas2
Adobe Employee
Adobe Employee
July 15, 2010

It would be very handy to have a flag for this. Our test sub-classes currently depend on the base classes doing some setup for them. Unless I am missing something, this is not possible with the new behavior without providing a customer sorter?

Many thanks,

Brian

Participating Frequently
July 15, 2010

Brian,

I think you might be missing something, that use case is exactly what people were looking for.

Given three classes A, B and C,

A is the base class

B descends from A

C descends from B

All of the Befores in A

     All of the Befores in B

          All of the Befores in C

               Test

          All of the Afters in C

     All of the Afters in B

All of the Afters in A

It prevents you from needing to keep track of hierarchy when specifying order. So, any order in B applies amongst the elements in B, however, the super class always runs before the sub on the way down and the opposite on the way back. Before, with multiple levels of hierarchy, it could get really confusing to manage.

If this does break things for you though, it is an easy setup. We didn't remove the old sorter, so it is still in the project and can be passed in as part of a Request().sortWith() or we can just provide some other way to indicate the older one should be used.

Hope that makes it clearer,

Mike