jmeter-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject [Bug 60987] New: Make setting variables predictable
Date Thu, 13 Apr 2017 17:41:13 GMT
https://bz.apache.org/bugzilla/show_bug.cgi?id=60987

            Bug ID: 60987
           Summary: Make setting variables predictable
           Product: JMeter
           Version: 3.1
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: Main
          Assignee: issues@jmeter.apache.org
          Reporter: jepp@cas.org
  Target Milestone: ---

Looking at Bug #53439, it was closed as Invalid.  But having hit a concurrent
problem, I believe the broader issue it raises should be addressed: there is
currently no obvious method for updating values of a variable, and the approach
currently required is counterintuitive and error-prone.

Background: Within JMeter, setting variables is generally prescribed as the
domain of the User Defined Variables config element.  Moreover, it is the only
element in the test plan that refers to user-defined variables specifically.

The problems with this are two-fold: 
1. it does not allow for scoped (re)definition of variables or their values
2. it does not adequately convey to the end-user that the config element is a
global, ordered-override accumulation that can be visited at most once per
thread and thus cannot be used for iteratively setting values.

The conventional wisdom is that updating the value of a variable involves a
JSR223 (or historically, Beanshell) sampler or pre/post-processor that calls
something like this:
vars.put("MY_VARIABLE", "new value");

This process is not well documented.  The closest the actual docs get is
section 21.3 (https://jmeter.apache.org/usermanual/functions.html#how), which
shows the vars.put() used in an inline beanshell call (as well as using Test
Plan variables as delegates) but doesn't clarify where this can even be used
(or binds the call to what seems to be an immutable value), let alone properly
stressing that vars.put() is the _ONLY_ way to manually set a value (so far as
I've been able to find).

I'm an engineer so I can live with this sort of tradeoff (if it's properly
documented), but asking users to write even a single line of code is
historically error-prone. (Did they use the right braces? Did they escape their
quoted string?  Why isn't ${__UUID} working? Do I need the semicolon there?
etc.)

One approach to resolving this would be to make the UDV ConfigElement properly
honour the scope of its placement in the test plan tree.  The other approach I
can see would be to add a "User-Defined Variable Setter Sampler" that presents
a similar interface to the ConfigElement but with proper scoping.

-- 
You are receiving this mail because:
You are the assignee for the bug.
Mime
View raw message