Skip to main content
A
adrian_aioanei
Participant
August 11, 2009
Answered

RemoteObject + AsyncToken

  • August 11, 2009
  • 1 reply
  • 2875 views

Seems that FlexUnit 4 passes a method marked with [Test(async)] even if inside it there is a real call to a RemoteObject using AsyncToken. The code looks like this:

[Test(async)]

public function testCreateProject():void

{

     var responder:IResponder = Async.asyncResponder( this,

          new TestResponder( verifyNewProjectResult, verifyNewProjectFault ), 5000 );

     var token:AsyncToken = remoteObject.createProject();

     token.addResponder( responder );

}

On the FlexUnit4 framework test cases here http://opensource.adobe.com/svn/opensource/flexunit/branches/4.x/FlexUnit4Test/src/flexUnitTests/flexUnit4/suites/frameworkSuite/cases/TestAsynchronous.as

there is a method that used the AsyncToken and TestResponder "testAyncResponderFaultWithTestResponder", but what happens there is not actually async as the result is sent right on the method scope with the token.applyResult. Actually going to the remote object will cause FlexUnit to pass the method as nothing was happening. Or am i missing something ?

Thanks in advance,

Adrian.

This topic has been closed for replies.
Correct answer mlabriola

Adrian,

I am going to confirm understand here before I jump into this. The AsyncReponder here acts as a bridge of sorts. It simply allows the test method to continue executing through an async event. Inherently, it does nothing to decide success or failure of a test.

If a test ends without making an assertion that is false, then it is a success. So, in this case, it would be up to you do assertions (or even just fails) in the verifyProjectResult and verifyNewProjectFault. You might want something to fail in a given case, and that failure is the correct result, so we can't make an assumption that just because the fault handler is called that the test fails.

So, if you wanted this to fail if the fault was called, you would need to do something like Assert.fail() in the verifyNewProjectFault.

If this is also your understanding and you don't believe it works, then I will file a bug and get someone to take a look.

Thanks,

Mike

1 reply

M
mlabriolaCorrect answer
Participating Frequently
August 11, 2009

Adrian,

I am going to confirm understand here before I jump into this. The AsyncReponder here acts as a bridge of sorts. It simply allows the test method to continue executing through an async event. Inherently, it does nothing to decide success or failure of a test.

If a test ends without making an assertion that is false, then it is a success. So, in this case, it would be up to you do assertions (or even just fails) in the verifyProjectResult and verifyNewProjectFault. You might want something to fail in a given case, and that failure is the correct result, so we can't make an assumption that just because the fault handler is called that the test fails.

So, if you wanted this to fail if the fault was called, you would need to do something like Assert.fail() in the verifyNewProjectFault.

If this is also your understanding and you don't believe it works, then I will file a bug and get someone to take a look.

Thanks,

Mike

A
adrian_aioaneiAuthor
Participant
August 11, 2009

I agree Mike. At first i thought that the handlers aren't triggered, but it seems that are. I'll use your suggestion about the Assert.fail() whenever a method fails unintended and have a different handler for some methods that are built to fail anyway.

Thanks,

Adrian.

Terms & ConditionsAccessibility statement
Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices