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: "Michaelis, Mark" <mark.michaelis@?.com>
  • Date: Thu, 6 Dec 2007 09:18:44 +0100

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

> >    --------------------------------------------------------

> >

> > Verweise

> >

> >    1. http://www.coremedia.com/

> >

> > _______________________________________________

> > qftest-list mailing list

> > qftest-list@?.de

> > http://www.qfs.de/mailman/listinfo/qftest-list

>

> --

> 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