Bug 60987 - Make setting variables predictable
Summary: Make setting variables predictable
Status: NEW
Alias: None
Product: JMeter
Classification: Unclassified
Component: Main (show other bugs)
Version: 3.1
Hardware: All All
: P2 enhancement (vote)
Target Milestone: ---
Assignee: JMeter issues mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-04-13 17:41 UTC by Wyatt Epp
Modified: 2017-04-13 17:41 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Wyatt Epp 2017-04-13 17:41:13 UTC
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.