Mailingliste - Einträge 2006

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: WG: [qftestJUI] generic component recognition

  • Subject: Re: WG: [qftestJUI] generic component recognition
  • From: Gregor Schmid <Gregor.Schmid@?.de>
  • Date: 20 Jul 2006 10:01:51 +0200

Hello Frank,

indeed, you cannot use an empty class, but you can use a common base
class, which is what I suggested in my answer (java.awt.Window for the
window and java.awt.Component for the component). If you like you can
even use java.lang.Object for both in which case it will also work for

Best regards,

"Neudert, Frank" <Frank.Neudert@?.de> writes:

> Hello, 
> I have also tried this method to access the components with some generic
> routines, driven by data read from a csv-File. This method is function
> properly. But  I am not able to create a generic_component without giving a
> class. And if I put there an empty variable, Qftest is not able zto find the
> component.
> As far as I see, you need to provide the class additional.
> with regards,
> Frank Neudert
> -----Ursprüngliche Nachricht-----
> Von: Nguyen, Tung [mailto:tnguyen@?.com]
> Gesendet: Mittwoch, 19. Juli 2006 23:03
> An: qftestJUI-list@?.de
> Betreff: [qftestJUI] generic component recognition
> Question:
> > I have one silly question that I hope you can help me with. From my 
> > testing with the Qftest tool thus far with the _default_ options 
> > setting, I've seen that a SUT's component will need to be recorded 
> > before it can be recognized and be used in a test case. Will this 
> > ALWAYS be the case? Or is there a Qftest's options setting as such I 
> > can provide a component's Id, for example, and the recognition 
> > algorithm will somehow figure out what component to use even if  that 
> > component has NOT been recorded previously?
> Greg's answer:
> If you have unique names in your generic components it's pretty easy to
> set things up in qftest for generic use.
> Manually create a Window node, id "generic_window" or like that,
> class java.awt.Window, all other attributes empty, though you may
> optionally use variables for name and or feature, e.g.
> $(genericWindowTitle) for the feature and $(genericWindowName) for the
> name. Define these variables with empty defaults at suite level.
> Below this, create a similar component node, id "generic_component",
> class java.awt.Component, name $(genericComponentName), rest empty.
> Don't define an empty default for genericComponentName, if you use the
> generic_component without this variable set it'll be an error. Then you
> can target any event to the generic_component and all you need to do is
> make sure that genericComponentName is set correctly.
> Of course you can also make use of the feature in a similar fashion.
> If you do so, set width and height of generic_component to some very
> large values, e.g. 100000 each. That way you'll not get a positive match
> unless name and/or feature are correct.
> Best move all of this into a separate test-suite along with procedures
> that operate on these components and include the suite where its needed.
> This is the most convenient way to handle this.
> _______________________________________________
> qftestJUI-list mailing list
> qftestJUI-list@?.de
> _______________________________________________
> qftestJUI-list mailing list
> qftestJUI-list@?.de

Gregor Schmid                                Gregor.Schmid@?.de
Quality First Software GmbH           
Tulpenstr. 41                                Tel: +49 8171 919870
DE-82538 Geretsried                          Fax: +49 8171 919876