Logo QF-Test

Finding valuable answers
in the Mailing List Archive.

 

Free Trial  Download  Buy

Thomas Max, QF-Test training and support

Use the full-text search on our web site to find helpful tips on the mailing list.

Thomas Max, 
Sr. Software Engineer & Trainer, QFS

2017 up to now  | 2016 | 2015 | 2014 | 2013 | 2012 | 2011 | 2010 | 2009 | 2008 | 2007

(older archive entries before 2007 are not shown here, but included in the onsite-search)

Mailing List - Entries of 2007


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

Re: [QF-Test] Non unique Ids cause poor performance


  • Subject: Re: [QF-Test] Non unique Ids cause poor performance
  • From: Gregor Schmid <Gregor.Schmid@?.de>
  • Date: 13 Sep 2007 22:43:39 +0200

Hello Yosi,

I haven't seen a reply to Karl's mail yet.

Frustrations on both sides aside, despite my not overly friendly reply
we will still do our best to help you with the problem at hand, _if_
you provide some data to work with.

The problem will not go away by itself. Please understand that your
problem is an individual one, not a generic failure of QF-Test and if
you don't give us more information, there's nothing we can do.

Best regards,
    Greg

Gregor Schmid <Gregor.Schmid@?.de> writes:

> Hello Yosi,
>
> thank you for pouring your frustration onto the mailing list instead
> of asking for support. I'm sure users will be delighted. Though I
> could do with venting some steam myself, I'll try not to answer in the
> same vein.
>
> Karl has already asked you to provide additional information. Please
> see below for further inline comments.
>
> "Yossi Loson" <yossi.l@?.com> writes:
>
> >    Hi Guys,
> >
> >
> >    I am working on one of eclipse's tools SWT (PDT) for several months now
> >    and still suffering from the non uniqueness of components
>
> Zend has support. Why are you not asking for help when the problem
> starts instead of building up a potential heap of waste over months?
>
> >    There are hundreds of components so working with non unique components
> >    cause very poor performance
>
> What exactly do you mean by "non unique components"? Are you getting
> "Non-unique component _id_" warnings when loading a test-suite or are
> you seeing non-unique _name_ messages in QF-Test's terminal?
>
> >    For instance: QFTest recognizes different component id for the same
> >    button in a simple test like going over the forms while creating a
> >    project
>
> Did you turn on the RCP name option?
>
> >    I already tried the following options:
> >
> >    1. Renaming each component in a unique name
> >
> >    2. Downloading the latest qftest build
> >
> >    3. Running the same test on the same eclipse (PDT) version
> >
> >    4. Removing & re-recoding components
> >
> >    None of the above works for the long run, this is very frustrating as
> >    the only way to somewhat work this issue out is by adding countless Try
> >    & Catch with a loop inside for each such component so component "X" can
> >    sometime recognize as "X1" and sometimes as "X13"
> >
> >    Furthermore when I upgrade to newer QFTest version sometimes the same
> >    component gets a different name altogether
>
> There haven't been any changes breaking or changing SWT component
> recognition after QF-Test version 2.0.2 which was released in March.
>
>
> >    I can't understand why can't you guys give unique name for each
> >    component base on the class/method path it is found in?
> >
> >    This will surly provide uniqueness
>
> You think we haven't thought about that? If there were a panacea for
> component recognition problems I'd give my right hand for it. But
> since you appear to be the expert here, please me the following:
>
> - Given a Widget at runtime, how do you determine a reference to it?
>
> - Given such a reference, how to find out what object it belongs to
>   and how to get the name of the attribute that holds the reference?
>
> - Even if the above were possible, what do you do in case of multiple
>   references?
>
> - How to work with private members? That's the one question I know how
>   to answer, but then what about obfuscation?
>
> - What if there isn't any reference besides the standard parent child
>   relationships?
>
> Even if you disregard all of the above and consider parsing source or
> byte code instead to instrument the SUT (something I'm sure some users
> will abhor, being afraid that the system tested might deviate too far
> from the original product):
>
> - How many attributes or local variables in average source code do you
>   think have useful names and how many are just named text1, text2...?
>
> - How many components are created on the fly or in generic methods
>   resulting in generic and definitely non-unique names?
>
> - How often do developers change the name of a variable?
>
> Perhaps we can find a way to use information about the source or
> byte-code to complement the component recognition mechanism, but it'll
> never be a reliable single source for component names.
>
> However, there already is such a source. PDT is a custom SWT plugin.
> As far as I know PDT is developed by your company. I can't understand
> why it is so hard for development to set names on components, at least
> the important ones. Or any kind other of reliable identifier - with
> it's NameResolver mechanism QF-Test could make use of anything
> provided.
>
> >    After using QFTest for quite a while now it seems it is not mature
> >    enough for our needs as no test run flows as expected
>
> I wonder whose maturity is at question here...
>
> Best regards,
>     Greg

--
Gregor Schmid                                Gregor.Schmid@?.de
Quality First Software GmbH                     http://www.qfs.de
Tulpenstr. 41                                Tel: +49 8171 919870
DE-82538 Geretsried                          Fax: +49 8171 919876
GF: Gregor Schmid, Karlheinz Kellerer          HRB München 140833


Videos Downloads Documentation Buy Free Trial