Logo QF-Test

Im Archiv der Mailingliste
wertvolle Antworten finden.

 

Gratis Testen  Download  Kaufen

Thomas Max, QF-Test Training und Support

Tipp für die Recherche in der Mailingliste: Volltextsuche (oben) verwenden.

Thomas Max,
Sr. Software Engineer & Trainer, QFS

2016 bis heute 2015 | 2014 | 2013 | 2012 | 2011 2010 2009 | 2008 | 2007

(ältere Archiveinträge vor 2007 nicht dargestellt, aber in der Suche enthalten)

Mailingliste - Einträge 2007


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

Re: [QF-Test] Serialization of Dependencies


  • Subject: Re: [QF-Test] Serialization of Dependencies
  • From: Gregor Schmid <Gregor.Schmid@?.de>
  • Date: 06 Dec 2007 14:48:46 +0100

Hello Mark,

the order of 'Dependency references' does matter. Basically, the
linearization algorithm is modeled after the C3 Method Resolution
Algorithm for linearization of OO class hierarchies with multiple
inheritance, coming originally from Dylan and adopted by Python for
Python version 2.3. A very good explanation - though not for the faint
of heart - can be found at

http://python.fyxm.net/2.3/mro.html

QF-Test dependencies and references are similar to a class hierarchy
with inheritance, with the additional complication that it is possibly
for one dependency to both reference dependencies and inherit
dependencies from the parent test-set.

But basically the linearization algorithm is the same. It tries to
enforce that: 

 - if A references B then B must come before A

 - if A references first B then C then B must come before C

 - if a test has dependency A and also inherits dependency B from its
   parent, then B must come before A

There were some bugs in the linearization algorithm of the early 2.1
versions, but to the best of my knowledge it works fine in 2.2.

Best regards,
    Greg


"Michaelis, Mark" <mark.michaelis@?.com> writes:

>    Hello Greg,
> 
> 
>    thanks for your insights about dependency handling. I must admit I am
>    still a "newbie" with QF-Test dependencies although I like them very
>    much.
> 
> 
>    Your question "Why do you need to restart the application?" made me
>    think. I read again the documentation and found the most important
>    hint: Only deal with one dependency at a time. Some dependencies I
>    wrote where rather large, doing a lot of preparation. Now I spent some
>    time on refactoring and especially took care of the characteristic
>    variables. And up to now it seems that this solved the problem. Now
>    restarting takes place because a characteristic variable has changed.
> 
> 
>    But I still feel an uneasiness using dependencies. Many questions arise
>    when using them. Questions especially about the linearization
>    algorithm. Is there a way to ensure that dependency "X" is called
>    before dependency "Y" when they are listed in the dependency-calls of
>    another dependency?
> 
> 
>    It is easy if dependency "Y" also depends on "X"... I will try to
>    mention a use case where this matters:
> 
> 
>    ·         Dependency "Application Started"
> 
>    o    Characteristic Variables: Username, Client
> 
>    ·         Dependency "userExists"
> 
>    o    Characteristic Variable: Username
> 
>    ·         Dependency "groupExists"
> 
>    o    Characteristic Variable: Groupname
> 
>    ·         Dependency "userInGroup"
> 
>    o    Call Dep: "userExists"
> 
>    o    Call Dep: "groupExists"
> 
>    ·         Dependency "groupHasReadRight"
> 
>    o    Call Dep: "groupExists"
> 
>    ·         Dependency "userLoggedIn"
> 
>    o    Characteristic Variable: Username
> 
>    o    Call Dep: "Application Started"
> 
>    o    Call Dep: "userExists"
> 
>    ·         Dependency "Application Ready for Test"
> 
>    o    Characteristic Variable: Username
> 
>    o    Call Dep: "userInGroup" (Username: e. g. Mark, Groupname: Users)
> 
>    o    Call Dep: "groupHasReadRight"
> 
>    o    Call Dep: "userLoggedIn"
> 
> 
> 
>    The problematic part is the sequence in the last dependency:
>    groupHasReadRight and userLoggedIn. groupHasReadRight must be called
>    before userLoggedIn but seeing the mere logic of dependencies QF-Test
>    might as well execute sequence "groupHasReadRight, userLoggedIn" just
>    as "userLoggedIn, groupHasReadRight". Or does the order in the call
>    dependencies also influence the order in which dependencies are called?
> 
> 
>    Perhaps I missed a part in the documentation, but this is not clear to
>    me.
> 
> 
>    Kind Regards
> 
>          Mark
> 
> 
> 
>    --
> 
>    Mark Michaelis
>    Software Engineer Quality Assurance
> 
>    CoreMedia
>    Ludwig-Erhard-Str. 18
>    20459 Hamburg, Germany
>    [1]www.coremedia.com
> 
>    --------------------------------------------------------
>    CoreMedia AG
>    Executive Board: Sören Stamer (CEO), Dr. Klemens Kleiminger (CFO)
>    Supervisory Board: Prof. Dr. Joachim Schmidt (Chairman)
>    Trade Register: Amtsgericht Hamburg, HR B 76277
>    --------------------------------------------------------
> 
> 
> 
>    > -----Original Message-----
> 
>    > From: Gregor Schmid [mailto:Gregor.Schmid@?.de]
> 
>    > Sent: Wednesday, November 28, 2007 9:33 PM
> 
>    > To: qftest-list@?.de
> 
>    > Cc: Michaelis, Mark
> 
>    > Subject: Re: [QF-Test] Serialization of Dependencies
> 
>    >
> 
>    >
> 
>    > Hello Mark,
> 
>    >
> 
>    > I guess answering that question is my job... :-)
> 
>    >
> 
>    > I'm considering implementing something akin to a 'Call dependency'
> 
>    > node that would let you resolve dependencies from any point in a
>    test.
> 
>    > Perhaps with an option to only roll back the stack up to a given
>    point
> 
>    > without rebuilding it anew.
> 
>    >
> 
>    > On the other hand I have not yet been convinced that this is really
> 
>    > necessary. Same for your case. Ask yourself: Why do you need to
> 
>    > restart the application? What's the difference between the
> 
>    > invocations? Let's say it's a parameter for startup. Put that
> 
>    > parameter in a variable and make that variable characteristic for the
> 
>    > "Application started" dependency. That way, if your app is running
> 
>    > with one setting your next 'Test-case' depends on the app being
> 
>    > started with a different setting - meaning the variable now has a
> 
>    > different value, QF-Test will roll back the dependency (i.e. execute
> 
>    > it's Cleanup node which is supposed to stop the application) so that
> 
>    > upon execution of the new Setup it will need to start the app again.
> 
>    >
> 
>    > If you really need to stop and restart the app within a single
> 
>    > test-case, move startup and shutdown sequences to procedures which
>    you
> 
>    > can call from the dependency as well as from any other place.
> 
>    >
> 
>    > I know, that's not quite the same because it doesn't take care of
> 
>    > proper rollback of the dependency stack.
> 
>    >
> 
>    > Further input, anybody?
> 
>    >
> 
>    > Best regards,
> 
>    >     Greg
> 
>    >
> 
>    > "Michaelis, Mark" <mark.michaelis@?.com> writes:
> 
>    >
> 
>    > >    Hello,
> 
>    > >
> 
>    > >
> 
>    > >    I would like to ask you what you would suggest for the following
> 
>    > >    problem concerning dependency linearization:
> 
>    > >
> 
>    > >
> 
>    > >    If I got the algorithm in QF-Test right dependencies are
> 
>    > linearized in
> 
>    > >    that way that independent dependencies are called in any
> 
>    > >    "non-predictable" order. If I got this idea right I have a
> 
>    > problem:
> 
>    > >
> 
>    > >
> 
>    > >    I have the following dependencies:
> 
>    > >
> 
>    > >
> 
>    > >    ·         Application Started
> 
>    > >    Ensures that the application is started and ready for test. This
> 
>    > is the
> 
>    > >    node called most often.
> 
>    > >
> 
>    > >    ·         Application Stopped
> 
>    > >    This dependency shall ensure that the application is stopped.
> 
>    > Example
> 
>    > >    would be to change some configuration files etc.
> 
>    > >
> 
>    > >    ·         Application Restarted
> 
>    > >    Now I have tests where I need to ensure that the application is
> 
>    > >    restarted from scratch. At least this is the current solution I
> 
>    > have in
> 
>    > >    mind. To do so I have to ensure the application is stopped and
> 
>    > then
> 
>    > >    started again. This can of course be done moving the
> 
>    > stopped/started
> 
>    > >    preparation nodes to procedures I will call. But the solution I
> 
>    > think
> 
>    > >    of would be:
> 
>    > >
> 
>    > >    o    Dependency: Application Restarted
> 
>    > >
> 
>    > >    §  Sequence
> 
>    > >
> 
>    > >    ·         Depend on Application Stopped
> 
>    > >
> 
>    > >    ·         Depend on Application Started
> 
>    > >
> 
>    > >
> 
>    > >    I. e. I would like to allow the Sequence Node as direct element
> 
>    > below
> 
>    > >    the Dependency node with the effect that Application Stopped
> 
>    > dependency
> 
>    > >    is ensured to be put in front of Application Started during
> 
>    > >    linearization.
> 
>    > >
> 
>    > >
> 
>    > >    What do you think? Does this make sense? Is it worth a feature
> 
>    > request?
> 
>    > >    Or do I treat the dependencies wrong?
> 
>    > >
> 
>    > >
> 
>    > >    Any hints welcome.
> 
>    > >
> 
>    > >
> 
>    > >    Kind Regards
> 
>    > >
> 
>    > >    *** Mark
> 
>    > >
> 
>    > >
> 
>    > >
> 
>    > >    --
> 
>    > >
> 
>    > >    Mark Michaelis
> 
>    > >    Software Engineer Quality Assurance
> 
>    > >
> 
>    > >    CoreMedia
> 
>    > >    Ludwig-Erhard-Str. 18
> 
>    > >    20459 Hamburg, Germany
> 
>    > >    [1]www.coremedia.com
> 
>    > >
> 
>    > >    --------------------------------------------------------
> 
>    > >    CoreMedia AG
> 
>    > >    Executive Board: Sören Stamer (CEO), Dr. Klemens Kleiminger
>    (CFO)
> 
>    > >    Supervisory Board: Prof. Dr. Joachim Schmidt (Chairman)
> 
>    > >    Trade Register: Amtsgericht Hamburg, HR B 76277
> 

-- 
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 Dokumentation Kaufen Gratis Testen