FlexUnit 4 assert failures have "explosive" stack traces

Not a bug and fully expected behavior.

FlexUnit 4 is really just a collection of runners that can handle just about anything that is thrown at it as well as handle any pluggable runners that others write. The level of extensibility comes with some complexity. So, by the time that single method of yours is executed, there are actually probably a hundreds methods in the framework for getting everything setup, inspected and ready to go.

The stacktrace always looks up the stack from your failure to the last point where a particular chunk of code execution began, so the 60 is basically just that number of methods. There isn't a whole lot that can be done about it save for eventually provinding filtering to eliminate showing some of our stuff and making the track more legible.

Regarding the async thing, your method isn't async but FlexUnit4 is. Inside of the Flash Player we are operating on frames. We don't have the luxury of threads and the like that Java has, so we have to handle the possibility that something might be async on a much deeper level. We also do something called green threading where we actually watch how much time we take in execution. Once we have taken 90% ish of the time available in a given frame, we wait until the next one before we begin executing again. This allows us to run long and compelx test suites without getting a timeout from the flash player (which happens if any single frame takes longer than 15 seconds to execute). So, even though your method isn't doing anything async, all of these other pieces have to account for the chance that something will be. Hence the reason that you see async pieces in the stack trace.

Hope that helps,

Mike