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

Trying to avoid a maintenance nightmare...

Expand Messages
  • davis3792
    Hi folks, I was thrilled when I ran across this module...now if I can just understand how to use it without creating a maintenance nightmare. :) My overall
    Message 1 of 3 , Dec 21, 2005
    • 0 Attachment
      Hi folks,
      I was thrilled when I ran across this module...now if I can just
      understand how to use it without creating a maintenance nightmare. :)

      My overall goal is to use GUITEST to implement "synthetic"
      transactions for response time monitoring. Timings from the
      different GUI operations will most likely be shoved into an rrdtool
      database for reporting. There are tools on the market from the likes
      of HP (OVIS), BMC, Mercury, etc that do similar things, but I'm not
      currently in a position to fund such a purchase. And I like Perl. :)

      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 did
      struggle quite a lot with finding the right combination of wait
      commands, but so far so good.
      Using winspy, I can see all of the fields/control on the ticket
      form...but was disappointed to see that the field labels don't show
      up. I as hoping to use the labels to locate and navigate to
      particular controls.
      I'm guessing this is a common problem??? The control id's appear
      to be unique (for this app) within a form. But I suspect that if the
      form is changed (new field, etc), the control id's might be reordered
      or changed.

      I really want to avoid creating something that is unreliable and
      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)?

      Thanks much.
    • Piotr Kaluski
      Well, well. An interesting e-mail. ... A very reasonable concern. Test scripts dealing with many controls are really prone to become difficult to maintain. ...
      Message 2 of 3 , Dec 22, 2005
      • 0 Attachment
        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 are
        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 did
        > 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 like
        to hear how did you solve it.

        > Using winspy, I can see all of the fields/control on the ticket
        > form...but was disappointed to see that the field labels don't show
        > 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 text
        field with a label describing it, then the label and edit field are
        separate controls. There is no direct link between them (on the Win32
        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 the
        > form is changed (new field, etc), the control id's might be reordered
        > 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 and
        > 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, try
        reading this:
        http://www.piotrkaluski.com/files/lguitest/introduction/index.html
        If you find it interesting, let me know.


        --Piotr
      • 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 3 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:
          WaitWindowLike
          FindWindowLike
          SetForegroundWindow
          WaitForReady

          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...
          Regards,
          JD

          --- In perlguitest@yahoogroups.com, "Piotr Kaluski" <pkaluski@p...>
          wrote:
          >
          > 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
          are
          > 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
          did
          > > 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
          like
          > to hear how did you solve it.
          >
          > > Using winspy, I can see all of the fields/control on the
          ticket
          > > form...but was disappointed to see that the field labels don't
          show
          > > 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
          text
          > field with a label describing it, then the label and edit field are
          > separate controls. There is no direct link between them (on the
          Win32
          > 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
          the
          > > form is changed (new field, etc), the control id's might be
          reordered
          > > 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
          and
          > > 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,
          try
          > 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.