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: Sat, 07 May 2005 09:12:02 -0000

Hello Yuri,

before you go any further: You _don't_ need to assign _all_ the
parameters _all_ the time. In fact, that would render default values
completely useless.

Parameters are passed through from the outer procedure call to the
inner procedure call quite naturally.

Your main problem is that you are defining too many (and especially
different) default values.

In your example, ExternalProc and InternalProc have different default
bindings for var. qftest's interpretation of such a situation is that,
without further definitions, the default binding in the innermost
procedure InternalProc is stronger that the binding in ExternalProc.

Your initial idea to override this was to add a binding var=$(var) to
the ProcedureCall node that calls InternalProc from ExternalProc. That
doesn't work because qftest variable expansion is lazy and $(var) is
not expanded at the time of the call, but later at the time of

As you correctly stated, the intended solution is to specify the value
you really want in the _outer_ ProcedureCall node that calls
ExternalProc. If you use the procedure chooser with copy parameters
enabled, you'll get that binding suggested anyway. This creates an
explicit binding that overrides both default values in both

There is one problem with this solution:

Each and every call to ExternalProc has to specify the value for var.
If you decide that this value should be different, you need to change
it in all calls to ExternalProc, changing the default value won't do

If, on the other hand, you were to put the explicit value into the
call to InternalProc from ExternalProc, you'd make it impossible to
override the value in the outer call.

Actually, a non-lazy (or "immediate") binding of var=$(var) at the
time of the inner ProcedureCall would be an ideal solution. However,
there are situations where lazy bindings are useful and some things
cannot be achieved without them. Also, we cannot simply switch from
lazy to immediate bindings as that would break backwards

Our current plans are to add an "immediate" flag to each variable
binding in a procedure so you can define whether you want lazy or
immediate expansion on a case by case basis.

For your current situation, I don't think there's a simple solution
that can be automated. The problem arises only in cases where an outer
procedure defines a default value for a variable that is different
from the default value of the variable in an inner procedure.

One question is: Why does this situation arise at all? I can't
remember any constructs from our own tests of from consulting
experience where we use something like that. Are you sure it's what
you want? Does it really make sense to have different default values
for the same variable? If the answer is yes, you can use the following
(ugly but useful) workaround:

Before the inner ProcedureCall, add a "Set variable" node to bind the
local variable tmp = $(var). This forces immediate expansion. Then
change the procedure call to set var = $(tmp).

This hack is necessary only in the context of nested procedures with
differing default values. I don't think you need to change any of your
other procedures or procedure calls.

Best regards,

P.S.: The above temporary variable binding hack is also very useful
for you cross-test-suite procedure calls where you need to specify
something like ${qftestJUI:suite.dir} as parameter. If the called
suite is located in a directory other than the calling suite's there's
a major difference between lazy and immediate expansion.

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

> Hi Greg, Karl, and all!
>    As I now know, when calling a procedure that have a 'var' parameter I
> can easy damage the external var definition when setting var to $(var)
> in the procedure call. Now I managed to reproduce it in a small example
> - it's attached: ParamLost.qft
> SkipParam.qrz - default value in InternalProc procedure is look result,
> not the one specified in it's call from ExternalProc.
> SupplyParam.qrz - shown that when the parameter value is given in
> ExternalProc call - the lookup in InternalProc founds those given value.
>   I red the manual chapter 9, and understand now it is correct behavior,
> not a bug. I wrote test-suites with many procedures, thinking the
> variables in procedure are parameters, passed by value. This is my fault
>   As I understand, the way to fix my fault is to substitute every
> parameter in each call of any procedure.  (Is it correct?)
> Currently I'm looking for a way to automatically verify all calls are
> supplying all the procedure parameters.  Is there any way, or I have to
> program such fix myself?
> When writing a procedure call and choosing a procedure there is a very
> useful option 'Copy parameters'. Unfortunately in many procedures
> parameters were added later - after these procedures were already used
> in many scripts.
> 	Thanks
> Yuri Tsyganenko

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