If I look at the mouseClickHandler() of the ListBase class it dispatches a ListEvent.ITEM_CLICK event specifying the x and y of the user's click on the column and row and also specifying the itemRenderer in the event.
However, I do not know if this will work or not. The problem with testing things like List as a whole piece is that they are composed of so many coupled units of code, you don't have a clean way to separate them and isolate anything.
The other code which might be helpful is the dispatching of the ListEvent.CHANGE which has similar information... but I don't know if you will be able to dive far enough into the List to get the references you need to dispatch this event. Does this need to be an integration/functional test or could you mock the List dependency and make this easier on yourself?
The other route here when dealing with whole components is to use the automation apis (which tools like FlexMonkey use) to gain appropriate visibility into the object
I don't think we're talking about the same components. The spark version of ListBase (spark.components.supportClasses.ListBase) doesn't have a mouseClickHandler() method, or any other method that seems to do what you described. Unfourtuantely this is an integration test so mocking is out. Also, I've tried FlexMonkey in the past but since FlexMonkey can't be run in a headless environment that's not really an option either.
1 person found this helpful
Okay. Keep your eyes open on the FlexMonkey front... some cool things there coming with FlexUnit.
You are right about the mouseClick thing. I was looking at the wrong version. What you are looking for in the 4.x ListBase is IndexChangeEvent.CHANGE
It is dispatched in commitSelection() of List. Seems to take a oldIndex and a newIndex. This is the default event for all changes to selectedIndex or selectedItem when the user interacts. valueCommit is the event if it is done programatically.
So, I could set the selectedIndex or selectedItem programatically, then dispatch this event
e = new IndexChangeEvent(IndexChangeEvent.CHANGE);
e.oldIndex = oldSelectedIndex;
e.newIndex = _selectedIndex;
I finally found the solution. IndexChange wasn't quite what I needed but it got me thinking about ways I could get a target for the event dispatcher. The item_mouseDownHandler() of ListBase is the method responsible for dealing with the user clicking on an item in the list. It takes a MouseEvent.MOUSE_DOWN event, which is simple enough, the tricky part was figuring out the component of the list that actually listenes for the mouse event. ListBase adds mouse down listener to the ItemRenders so I had to get the ItemRenderer instance that corresponded to the index I wanted to select. To do that I just had to call getElementAt( index:int) on the dataGroup of the list and pass the result into the SequenceEventDispatcher as the first parameter.
One thing to watch out for. If you are trying to test a DropDown, you need an additional async handler or sequence to wait for the dropdown to be opened. If you try to do the whole process at once then dataGroup will be null and you get an NPE.
Here is a simplified version of the solution I came up with. If anyone wants to see the more complicated version that tests a DropDownList let me know and I'll be happy to share.
public function testSelectSomething():void
var sr1:SequenceRunner=new SequenceRunner(this);
//wiz is the parent container for the List
failFunc("item never selected")));
FlexMonkey is easily run in a headless environment by using a virtual framebuffer such as xvfb.
FlexMonkey seems the way to go, complex UI stuff like this seems like nightmare to do in code, quite often the logic in these lists changes in the sdk's, although I guess you would have to rewrtie the tests also for FlexMonkey