To answer these questions:
First, the async property actually causes this test to take a separate
path internal to the runner. Without the async tag, much of the code
is assumed to be synchronous and runs without the safety net necessary
for async to occur. With the async property, that code is enabled.
This purely a performance issue. Things are slower when we need to
create handlers and logic to consider async communication.
The timeout itself can be ignored at this moment for your purposes.
This defines a timeout window for the whole test as I might have (n)
asynchronous steps that occur as part of one test. This serves as a
way for me to collectively indicate that they should take no more than
500ms. The timing on the individual handlers indicates how long each
sub-step might take. Truthfully, this is more confusing than it needs
to be and we need to find a way to simplify this a bit.
Mike
On Sep 30, 2:06 pm, Jesse Warden <
jesse.war...@gmail.com> wrote:
> Ok, so I'll ask here then since technically fluint is backwards compatible
> with the RunWith.
> Why use [Test(async,timeout="500")] when you:
> - have to use the var response:Function = Async.asyncHandler thing anyway
> - and you have to set the timeout in that above function as well; I don't
> get what the tag is doing...
>