FlexUnit 4 Error

I am facing a strange FlexUnit Error:

Whoa... been asked to send another complete and I already did that

The error seem to occur when the number of test exceede 27...? (the tests never complete)

test exemple:

[Test]
public function whenDoingThat_expectThatIsTrue():void{
      //blabla      
      assertTrue(...)
}

Any help welcome !

Here is an exemple:

core = new FlexUnitCore();
core.addListener(new TraceListener());
core.run(FooTest);


import org.flexunit.asserts.assertTrue;

public class FooTest {
    [Test]
    public function foo_test_1() : void {
        assertTrue(true);
    }
    [Test]
    public function foo_test_2() : void {
        assertTrue(true);
    }

    ...

    [Test]
    public function foo_test_28() : void {
        assertTrue(true);
    }
    //[Test]
    public function foo_test_29() : void {
        assertTrue(true);
    }
}

result:

foo_test_9 .
foo_test_17 .
foo_test_3 .
foo_test_18 .
foo_test_4 .
foo_test_19 .
foo_test_5 .
foo_test_6 .
foo_test_20 .
foo_test_21 .
foo_test_7 .
foo_test_22 .
foo_test_8 .
foo_test_23 .
foo_test_2 .
foo_test_24 .
foo_test_10 .
foo_test_25 .
foo_test_11 .
foo_test_26 .
foo_test_12 .
foo_test_27 .
foo_test_13 .
foo_test_28 .
foo_test_14 .
开发者_JAVA技巧foo_test_15 .
foo_test_1 .
foo_test_16 .
Whoa... been asked to send another complete and I already did that

Ironic this is posted here, considering the actual problem is really a StackOverflow:

https://bugs.adobe.com/jira/browse/FXU-112

You can use the workaround mentioned in the bug, or this behavior is fixed in FlexUnit 4.1 beta, which can be found on the flexunit.org download page.

A release version of 4.1 is coming very shortly.

The problem is your machine is fast enough to get one extra test in before the framework forces it to wait until the next frame. Flash Player throws a Stack Overflow when that stack depth gets to deep and it is being caught in a try catch in an inopportune place, and subsequently tracing out the 'Whoa' statement.

In FlexUnit 4.x originally, we used a counter and an approximate frame length for this, which, on very rare occasions linked more to the machine than the tests, could allow this to occur. In 4.1 we actually monitor the frames as they go by which should permanently eliminate this problem.

Mike