Loading ...
Sorry, an error occurred while loading the content.

Re: Trying to avoid a maintenance nightmare...

Expand Messages
  • JD
    I m not sure that I ve really solved anything relative to the problem of waiting. I finally gave up and put in a sleep after a button push...I could not find
    Message 1 of 3 , Dec 22, 2005
    • 0 Attachment
      I'm not sure that I've really solved anything relative to the problem
      of waiting. I finally gave up and put in a sleep after a button
      push...I could not find a way to dependably wait until the
      functionality behind the button push completed and returned control
      (all the button was doing was clearing out a bunch of fields on a
      search form).

      Until that point I'd had success using a local function (that I
      wrote) that issues the following calls:

      I invoke this subroutine whenever I perform an operation that hands
      control to the gui. But since the button episode, I'm starting to
      wonder if I haven't duped myself - that all of the function call
      overhead and delay isn't doing the equivalent of a sleep!!!

      Relative to the labels...
      What you're saying makes sense.
      (NOTE: I'm not very experienced in the win32 space - much more of an
      old unix guy.)
      The labels do NOT show up in winspy. In the forms developer
      associated with the application, the label and input field (or
      dropdown, etc) are "one" control that you drop on a form - the label
      being an "attribute" of sorts of the control that you fill in - which
      in my ignorance led me to believe there would be a discernable
      relationship within the win32 hierarchy. Note also that in this
      application, the label can act as a link to drill into an underlying
      object. If the label is red in color and underlined, you can mouse
      click on the label and it will bring up another form (example: click
      on a employee name field and it will pop up the full employee record).
      So if I continue down the guitest path, I'm going to have to teach
      the perl program how to click on the links.
      I'm very concerned about the reliability aspect - especially given
      that I would be trying to measure service levels (ie. SLA's)! And I
      was really hoping to avoid having to change the perl program
      everytime a develop adds a field to a form.

      Relative to the control ID's:
      In this case, the control ID's certainly appear to be unique on a
      given form. So that may be my best option for identifying
      fields...but it certainly doesn't live up to uninformed expectations.
      I'm very curious how the HP and Mercury products would handle this
      application. I'm pretty sure that BMC's (PETE) product strictly
      records screen coordinates.

      I look for forward to reading the link you posted...

      --- In perlguitest@yahoogroups.com, "Piotr Kaluski" <pkaluski@p...>
      > Well, well.
      > An interesting e-mail.
      > > now if I can just
      > > understand how to use it without creating a maintenance
      nightmare. :)
      > A very reasonable concern. Test scripts dealing with many controls
      > really prone to become difficult to maintain.
      > > I have an old CRM Win32 application that I'm trying to build
      > > against. So far I can login, use a menu to open a search form,
      > > lookup a particular case/ticket, and open the located ticket. I
      > > struggle quite a lot with finding the right combination of wait
      > > commands, but so far so good.
      > You mean you managed to find a way of smart waiting until a
      > transaction ends? I find it a headache in gui testing, so I would
      > to hear how did you solve it.
      > > Using winspy, I can see all of the fields/control on the
      > > form...but was disappointed to see that the field labels don't
      > > up. I as hoping to use the labels to locate and navigate to
      > > particular controls.
      > Static labels are controls by themselves. If your form contains a
      > field with a label describing it, then the label and edit field are
      > separate controls. There is no direct link between them (on the
      > level). Therefore it would be difficult to use labels for navigation
      > between editable controls. Can you see those labels in Winspy?
      > > The control id's appear
      > > to be unique (for this app) within a form. But I suspect that if
      > > form is changed (new field, etc), the control id's might be
      > > or changed.
      > It is probably a good programming practice to keep all control ids
      > different, but it is not a requirement. It happens pretty often to
      > find a window which has many children with the same control id (most
      > commonly this id is "0").
      > > I really want to avoid creating something that is unreliable
      > > vulnerable to even slight form changes.
      > >
      > > What are my alternatives for creating a manageable solution?
      > > Why don't the labels show up (no doubt my ignorance about
      > > controls)?
      > >
      > I was trying to develop a solution for it. If you have some time,
      > reading this:
      > http://www.piotrkaluski.com/files/lguitest/introduction/index.html
      > If you find it interesting, let me know.
      > --Piotr
    Your message has been successfully submitted and would be delivered to recipients shortly.