2018 up to now | 2017 | 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: 12 Sep 2007 08:40:03 +0200

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

- 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

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

>    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,

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