seleniumflexapi-development

Re: [Seleniumflexapi-development] Flex Selenium

[Fergal H. <fer...@gm...>]

Hi Steve,

Aswers and questions below:

On Thu, Jun 18, 2009 at 2:36 AM, Booth, Steve <ste...@hp...> wrote:

>
> Hello Fergal and Scott,
>
> Jason Fountain, with whom you've exchanged email recently, has been working
> with my team on a Flex/Selenium project.
>
> I'd like to follow up with a question or two, and hope you can spare time
> to reply.
>
> It seems to me that some external influence might be necessary to deal with
> a cascading menu bar.  An existing method, clickMenuBarUIComponent, works
> with a single menu cascade, but not for 2 or more.
>
> I'm new to this, so please bear with me. Given the (apparent)
> single-threaded nature of what I see in the ".as" files, it seems that after
> the first menu item is found, we need to allow a repaint to occur between
> each subsequent menu cascade.  Only with the repaint will we find a
> populated MenuBarItem.
>
> If that is a correct understanding of the beast, then I am willing to share
> some code I wrote, with approval from my management.  What I have works for
> us - the question is whether the approach is sufficiently generalized for
> the global community.
>

The MenuItem object exists and is clickable even before a repaint occurs.
For example if you gave your MenuItem an id then you could just use the
flexClick command to directly click it without having to navigate the menu
and wait for cascade. That said I think this isn't the way tests should be
performed that require clicking menu items.


> So, here are the questions:
>
> Q1:  Is it generally true that a repaint is necessary for each subsequent
> menu cascade? [Note: We have a proprietary way to short-circuit this, but
> I'm trying to establish a "general use" behavior]
>

Repaint is not necessary but ideally a repaint should occur as to model user
interaction. Any departure from this and your getting into unit-test
territory of which there are better solutions than the Selenium Flex API.
Could you explain a little more about your proprietary solution?


>
> Q2:  Within the design constraints you have for your Flex/Selenium work, is
> it OK to expect users to poll for a "menu sequence done" condition, after
> making a call to initiate the sequence?
>

I've proposed earlier a new method for navigating menus whereby the tester
enters an address string for the MenuItem they want to click and the waiting
between repaints is handled by the API *internally* and is based on the
delay setting for the component.  For example such a command would look
like:

Command: flexClickMenuItem
Target: myMenu1~mySubMenu~myMenuItem1
Value:

Trying to directly click the menuitem would throw an error. And if the
MenuItem was in a radio group or checkable

 Command: flexSetMenuItem
 Target: myMenu1~mySubMenu~myMenuItemSelection1
 Value: true

I propose using the Tilda to delimit the menuItems because we want to
reserve the dot for supporting fully qualified names in the target parameter
(a feature to be added soon).

Anyway, thanks for your interest in the project Steve. I hope I could answer
questions appropriately. Has there been much interest in this project over
there at HP? If you guys want to get more involved then get onto the
developers mailing list. The project is going to go through a phase of high
activity over the next few weeks so it might be fun to get in on it.


Thanks,
Fergal


>
> Thanks for your time,
> Steve Booth

Re: [Seleniumflexapi-development] Flex Selenium

[Fergal H. <fer...@gm...>]

Hi Steve,

In regards to the point of confusion, the object should exist so long as the
data binding to the MenuBar is updated before clicking the first menu. If
clicking on the first menu is what triggers the dataProvider source object
to be populated then the object won't exist until that happens.

Answers below for your other questions:

On Thu, Jun 25, 2009 at 8:19 AM, Booth, Steve <ste...@hp...> wrote:

>  Hi Fergal,
>
> I've asked my management for approval to share what I have.  I should get a
> response within 2 days.
>
> In the meantime, I'm confused about one of your responses (I commented your
> email, below).
>
> I've also forwarded your email to my team, with hope there is sufficient
> interest to get people onto the developers email list.  We're still
> wrestling with several problems, and some interaction would seem warranted:
>
>    - we haven't yet had success navigating a 'tree' (expanding '+'
>    buttons, collapsing '-' buttons, etc)
>
> There needs to better support for tree components in the API. Something
we're taking on for the next release which should be out in about 2 weeks

>
>    -
>    - we're trying to establish a good generic way to access UI components
>    that might exist in the header of a DataGrid (e.g., like a checkbox to
>    select "all" datagrid rows) [i.e., we're pretty much novices over here]
>
> There's a bug in the API that sometimes prevents interaction with objects
embedded in other components. We're looking into this currently and will
have a fix in the next release. Have you tried running the refreshIDTooltips
command to see if the id can be located on the component?

>
>    -
>    - non-unique IDs; we haven't yet deciphered how to uniquely scope
>    objects that have the same ID; the AppTreeParser code seems to support the
>    "/" character for scoping, we just have to figure out how to use it properly
>
> There are 2 main ways to uniquely identify objects with the same id:

   1. using the "/" this is done by specifying a unique container component
   to narrow the search scope to that; followed by the id of the target
   component. For example myCanvas/myButton  - this method is the most stable
   in terms of coping with changes on the UI.
   2. using index for example myButton[3]  - this is less stable as it can
   be hard to predict what index will be allocated to the component which can
   easily happen if the component are created in a different order for
   different test scenarios.


>    -
>
> Thanks for the information you sent us, and I'll let you know as soon as I
> hear from the management.
>
> Steve
>
>
>  ------------------------------
>  *From:* Fergal Hanley [mailto:fer...@gm...]
> *Sent:* Tuesday, June 23, 2009 6:45 PM
> *To:* Booth, Steve
> *Cc:* Scott Galloway (sbg...@gm...);
> sel...@li...
> *Subject:* Re: Flex Selenium
>
> Hi Steve,
>
> Aswers and questions below:
>
> On Thu, Jun 18, 2009 at 2:36 AM, Booth, Steve <ste...@hp...>wrote:
>
>>
>>  ... stuff deleted ...
>>
>> It seems to me that some external influence might be necessary to deal
>> with a cascading menu bar.  An existing method, clickMenuBarUIComponent,
>> works with a single menu cascade, but not for 2 or more.
>>
>> I'm new to this, so please bear with me. Given the (apparent)
>> single-threaded nature of what I see in the ".as" files, it seems that after
>> the first menu item is found, we need to allow a repaint to occur between
>> each subsequent menu cascade.  Only with the repaint will we find a
>> populated MenuBarItem.
>>
>>  ... stuff deleted ...
>>
>
> The MenuItem object exists and is clickable even before a repaint occurs.
> For example if you gave your MenuItem an id then you could just use the
> flexClick command to directly click it without having to navigate the menu
> and wait for cascade. That said I think this isn't the way tests should be
> performed that require clicking menu items.
>
>  Point of confusion: Suppose the MenuBar component is used to create
> MenuItems in a data-driven manner, using the dataProvider property.  Then
> the MenuItem objects don't exist (yet), do they?
>