What steps will reproduce the problem? 1. Create a TestCase with two test methods 1. add a call to addEventListener (with asyncHandler(pendUntilComplete) ) in the setUp AND the tearDown methods (like in the Wiki example) 2. add a breakpoint at the begining of the setUp, tearDown, pendUntilComplete and all the test* methods of the TestCase 3. Run the TestRunner in Debug

What is the expected output? What do you see instead? The breakpoints should be it in the following order: - setUp - pendUntilComplete - first testMethod - tearDown - pendUntilComplete - setUp - pendUntilComplete - second testMethod - tearDown - pendUntilComplete

But this order is this one instead: - setUp - pendUntilComplete - first testMethod - tearDown - setUp - fail("Asynchronous Event Received out of Order")

What version of the product are you using? On what operating system? dpUInt_b_v09_2_Flex_3.swc dpUInt Framework Beta v0.9.2 Flex 3

Please provide any additional information below. After some investigation, I found out that the problem resides in the handleTestProcess method of the TestRunner class. The validation for progressCursor.afterLast=true (line 350) is done right after the call of progressCursor.moveNext() (line 343). So if progressCursor.current is runTearDown(), progressCursor.afterLast will be true, hence setting testCompleted to true, which will automatically trigger handleTimerTick() to call handleTestProcess(null), restarting the loop before the first tearDown() has completed.

I fixed the bug by simply moving the validation for progressCursor.afterLast=true at the begining of the handleTestProcess() method. Since I can't commit directly, I've attached my version of TestRunner.as to this issue.

elpy,

We are checking this out right now. If everything is as you say, this change will be added to the next release.

Thanks,

Josh Berling (nerdCaps)

I have been experiencing the same issue. I applied the TestRunner.as to revision 125 and it corrected the problem for me.

I have a patch that fixes this. I don't think it's the "best" way to do it, that would probably take more changes to the TestRunner class but, this was the lowest impact way of doing it. Basically, change the hasAsyncPending getter of a TestCase to be public, then don't move the cursor unless you are afterLast && !hasAsyncPending.

Besides the path there is a simple example of an async teardown that is "broken."

In the example there are two test cases in the suite which do nothing except check a string that is set in the setup functions and trace "Test Running" to the console. Additionally, the setup and teardown both have a trace statements which say when they start e.g. "Setup Started" and when they end e.g. "Setup Completed".

With this information setup you'd expect the console out put to look as such: Setup Started. Setup Completed. Test running TearDown Started. TearDown Completed. Setup Started. Setup Completed. Test running TearDown Started. TearDown Completed.

But that is not the case, the output from this run is: Setup Started. Setup Completed. Test running TearDown Started. Setup Started. TearDown Completed. Test running Setup Completed. TearDown Started. TearDown Completed.

You can plainly see that the next test is beginning before the teardown has completed. After applying the attached patch, the result changes to: Setup Started. Setup Completed. Test running TearDown Started. TearDown Completed. Setup Started. Setup Completed. Test running TearDown Started. TearDown Completed.

Which is the correct pattern.

-d

I also ran into this immediately using Fluint. I applied Dan's patch and everything works perfectly now. Thanks Dan!

Please get this into SVN soon.

Patch applied to Fluint verson 1.0.