FlexUnit is throwing a RTE instead of being caught internally.
FlexUnit is actually throwing an error versus being caught internally... This is showing up as an RTE popup instead of a failed or error test.
task dispatch complete: - expected true but was false
at org.flexunit::Assert$/failWithUserMessage()[E:\hudson\jobs\FlexUnit4-Flex4.1\workspace\FlexUnit4\src\org\flexunit\Assert.as:306]
at org.flexunit::Assert$/failNotTrue()[E:\hudson\jobs\FlexUnit4-Flex4.1\workspace\FlexUnit4\src\org\flexunit\Assert.as:167]
at org.flexunit::Assert$/assertTrue()[E:\hudson\jobs\FlexUnit4-Flex4.1\workspace\FlexUnit4\src\org\flexunit\Assert.as:148]
at Function/http://adobe.com/AS3/2006/builtin::apply()
at global/org.flexunit.asserts::assertTrue()[E:\hudson\jobs\FlexUnit4-Flex4.1\workspace\FlexUnit4\src\org\flexunit\asserts\assertTrue.as:18]
at com.CLIENT.sitesurvey.business.startup::LoadConfigurationTaskTest/onResultCompleteHandler()[C:\Users\Drew\Documents\Clients\CLIENT\source\trunk\unitTests\tests\com\CLIENT\sitesurvey\business\startup\LoadConfigurationTaskTest.as:100]
at org.robotlegs.utilities.macrobot::AsyncCommand/dispatchComplete()[C:\Users\Drew\Documents\Clients\CLIENT\source\trunk\library\src\org\robotlegs\utilities\macrobot\AsyncCommand.as:63]
at com.CLIENT.sitesurvey.business.startup::LoadConfigurationTask/dispatchFailureEvent()[C:\Users\Drew\Documents\Clients\CLIENT\source\trunk\library\src\com\CLIENT\sitesurvey\business\startup\LoadConfigurationTask.as:83]
at com.CLIENT.sitesurvey.business.startup::LoadConfigurationTask/onFault()[C:\Users\Drew\Documents\Clients\CLIENT\source\trunk\library\src\com\CLIENT\sitesurvey\business\startup\LoadConfigurationTask.as:44]
at flash.events::EventDispatcher/dispatchEventFunction()
at flash.events::EventDispatcher/dispatchEvent()
at HTTPOperation/http://www.adobe.com/2006/flex/mx/internal::dispatchRpcEvent()[E:\dev\hero_private\frameworks\projects\rpc\src\mx\rpc\http\HTTPService.as:993]
at Function/http://adobe.com/AS3/2006/builtin::apply()
at mx.rpc::AsyncDispatcher/timerEventHandler()[E:\dev\hero_private\frameworks\projects\rpc\src\mx\rpc\AsyncDispatcher.as:50]
at flash.utils::Timer/_timerDispatch()
at flash.utils::Timer/tick()
Any thoughts?
The methods within the test that this is happening on are below... currently despite the name of the function, I'm passing an invalid URL.... Because the test runs fine locally through the IDE with a valid url, but is crashing Hudson (which is also running locally) with the same url.
[Test(async)]
public function testExecuteValidUrl():void
{
var task:LoadConfigurationTask = createTask("");
task.addCompletionListener(onResultCompleteHandler);
var successHandler:Function = Async.asyncHandler(this, onLoadCompleteHandler,500,null);
task.eventDispatcher.addEventListener(LoadConfigurationTask.LOAD_COMPLETE_EVENT, successHandler , false, 0 , true);
Async.failOnEvent(this,task.eventDispatcher,StartupFailedEvent.STARTUP_FAILED,500);
task.execute();
}
private function onLoadCompleteHandler(e:Event,passThrough:*) : void
{
assertTrue("Loading Complete", true);
}
The strange thing is that it is weird that some of the code looks like it is coming from my clients' folder, and the unit tests looks like it is coming from my Hudson installation.... I haven't figured that part out yet.
Thanks!
Keyboard shortcuts
Generic
? | Show this help |
---|---|
ESC | Blurs the current field |
Comment Form
r | Focus the comment reply box |
---|---|
^ + ↩ | Submit the comment |
You can use Command ⌘
instead of Control ^
on Mac
Support Staff 1 Posted by labriola on 05 Aug, 2011 10:56 PM
The stack trace shows the problem. Notice the stack trace starts with a timer tick and then doesn't contain the word flexunit until the point where you are calling asserts?
Asserts are basically throwing errors. Flexunit catches these issues and processes them. However, since errors move up the callstack, FlexUnit needs to be in the callstack to do anything about it... its not here
You are adding a completion listener directly for onResultCompleteHandler. When that listener fires you do an assert...flexunit has no idea that happened. Any asynchronous events must, in one way or another be registered with flexunit. that is basically what the async API does. It shims flexunit into the callstack to handle these issues
Other problem you are going to face is that the async api is really designed to help you do a unit test, which usually means to test one small unit. with several async events going on here, that becomes more than a unit. So, you will face other issues
I would look into the async startup apis to get your test case setup as needed and then try to keep your tests to just one condition. You will have more luck.
The multiple source paths are because some of this code is coming from a library and libraries retain the path info of where they were built in debug mode.
Mike
2 Posted by Drew Shefman on 08 Aug, 2011 05:49 PM
Makes perfect sense. Thanks for the explanation.