Can you wait for multiple events to fire?

[Robert]

I've been playing with Fluint for the past couple of days, and am
trying to run a test that is listening for databinding to occur before
I do a couple of asserts to check that the data has been updated
correctly.

I have two UIcomponents, textField1 and textField2, which are both
updated via binding to a single object on the presentation model.
After I dispatch an update event, I update the object on the pm, and
want to make the following asserts

1. assertTrue("Wrong user returned", _View.textField1.text ==
'rstestuser02');
2. assertTrue("Wrong first name!", _View.textField2.text ==
'Test');

If I use the following code:
sequence.addStep( new SequenceWaiter( _View.textField1 ,
FlexEvent.VALUE_COMMIT, 500) );

Then assert 1 always passes, but sometimes textField2 has not been
updated, and assert 2 fails.

If I listen to textField2 instead of textField1, then assert 2 always
passes, but assert 1 will sometimes fail.


Is there a way to listen to both being updated before proceeding, if
you do not know in which order the FlexEvent.VALUE_COMMITs will be
fired?

[Robert]

BTW I'm using SequenceWaiter with FlexEvent.VALUE_COMMIT because I
always get a #1034 Error when trying to use:

sequence.addStep( new SequenceBindingWaiter( _View.textField1 ,
'text', 500) );


TypeError: Error #1034: Type Coercion failed: cannot convert
flash.events::Event@49ce641 to mx.events.PropertyChangeEvent.

[Matt Hughes]

Not out of the box.  Though it would be pretty trivial to write a class to be added to Fluint that registers for N events and then throws a NEW event when all N events have arrived.  You would wait for that new event instead of waiting for each one.

The issue is that most of the time you don't know exactly the order in which the events will arrive.

[Michael Labriola]

I am pretty sure I disagree about doing this out of the box. You
should be able to add as many sequenceWaiters as you would like to a
sequence, one after another. So, one for the first item, and one for
the second. It will only move on in the sequence after both of those
have occurred. If this isn't working, then I think something is wrong,
altough I believe many of our test cases do exactly that.I will throw
together a quick prototype.

As far as your error with the SequenceBindingWaiter, good catch. There
is a bug on line 361 of TestCase. It looks like the
SequenceBindingWaiter was updated, but I missed a reference here. We
should be using a generic event in the function definition and using
unwatch instead of removeEventListener.

Mike

> > flash.events::Event@49ce641 to mx.events.PropertyChangeEvent.- Hide quoted text -
>
> - Show quoted text -

[Michael Labriola]

So, next time I will read the whole message. Matt is right. You can
listen to both if you know the order. If you do not know the order,
then there is no way out of the box. The idea of these tests would be
that the order is crucial that events occur, and, should they occur
out of order, that is actually an error

On Apr 1, 4:58 pm, Matt Hughes <hughes.m...@gmail.com> wrote:

[conrad.w...@googlemail.com]

Strictly speaking you should write two tests - one for textField1 and
one for textField2.

This is a more strict and clean approach to the single test you are
trying to make work.

:-)