Mailing list - Entries of 2005

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

Re: [qftestJUI] Automated way needed to substitute all parameters to calls

  • Subject: Re: [qftestJUI] Automated way needed to substitute all parameters to calls
  • From: Gregor Schmid <Gregor.Schmid@?.de>
  • Date: Sun, 08 May 2005 12:32:02 -0000

Hi Yuri,

I'm answering on the list again as that's where the thread started
and I think the discussion may be of general interest.

See below for my answer.

"Yuri Tsyganenko" <tsyg@?.com> writes:

> Hi Greg,
> Thank you for the idea of the hack. I tried it on the test-example, it
> works: I verified it does _not_ require the 'tmp' variable declaration
> in the block were the call is.
>   All such places may be found by text search for the places where
> 	<variable name="client">$(client)</variable>
> Or the regular expression (to search not just 'client' but any such
> case)...
>    Although having extra 'Set variable' item isn't nice, it looks the
> simplest solution.
> [Greg]> Why does this situation arise at all?
> Historically - not enough understanding...
> First, I wrote scripts with procedures and hard-coded the client value.
> Later on, another client was needed, and I put a parameter 'client' in
> some procedures that originally were without this parameter.
> In order to keep unchanged all the existing calls I used the default
> value of this parameter to the value as originally hard-coded.
> Later on newer procedures appeared, where the parameter is used, but
> default value is not set: in order to _require_ parameter assigning at
> call.
> Having many procedures and test suites I'm getting such combinations of
> procedure calls. Now I realized I can get crash in many places....
> [Greg]> Are you sure it's what you want?
> I'm not sure, still thinking:
> 1) to understand the conception of assigning 'client' in my scripts
> 2) to fix all existing test-suites
> [Greg]> Does it really make sense to have different default values
> [Greg]> for the same variable?
> The empty default values are considered as their declaration.
> It means: "it is requierd to set this value when calling". Having
> defined (non-empty) default value is used for compatibility with earlier
> calls: the calls that were made before the parameter appeared in the
> procedure.
> Thanks and best regards,
>  Yuri Tsyganenko

What we do ourselves is:

Use $(client) everywhere. There is not a single node with a specific
value for the client attribute. It is always implicit. As such, no
procedure ever defines a default value.

90% or more of all tests work with a single SUT client only. For that
we define the default value for "client" in the suite variables, i.e.
in the root node of each test-suite that can be run standalone in
batch mode.

Additionally, our startup sequences typcially contain a "Set variable"
node that sets the global "client" to $(client). On first sight this
may seem stupid, but actually it propagates the definition of "client"
from suite to global level. During interactive test-development this
means we can execute sequences in any suite without requiring "client"
to be defined there.

Those parts of tests that actually control multiple SUT clients
expressly define values for "client" only where it deviates from the
default. This may be done in procedure calls, or in Sequence or Test
nodes. A typical test may look like

+ Test with two SUT clients
  + Sequence: Do in the default SUT client
    + ...
  + Sequence: Do in the other SUT client
    ("client" bound to non-default value)
    + ...
  + Sequence: Do else in the default SUT client
    + ...
  + Sequence: Do else in the other SUT client
    ("client" bound to non-default value)
    + ...

Best regards,

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