I'm pretty sure that Request Defaults is only evaluated once at compilation so
it won't be dynamic but there are lots of ways to do what you want.
Could you send /foo?verboseLogs=false as a request? If so, that would make
things very neat, you could just pass in the value for verboseLogs using -J.
Also, what happens if you send /foo?verboseLogs=undefined? If this is
acceptable (ie. it gets ignored) then this makes things even simpler.
If you really only want to specify this param when desired then you could use
beanshell to build a var that is null when not required, so you'd have
/foo${myParamVar} (I guess null values are acceptable, I'm not certain of this
though).
And then, yes, you could have separate requests with conditional logic wrapped
around them but, like you say, this is a bad solution as it creates duplication.
On 3 Aug 2012, at 00:01, Stephen Ash wrote:
> In the following test plan example, the HTTP Request Defaults element
> is applied to all HTTP Samplers. Is there a way to modify that test
> element dynamically during the test execution?
>
> The use case is that each of the /foo, /bar, /baz requests can take an
> optional request parameter. So both GET /foo and GET
> /foo?verboseLogs=true would be valid requests. I was looking for a way
> to pass in a property (-JoptionalParameters=true) to JMeter in order
> turn on or off those arguments.
>
> Test Plan
> - HTTP Request Defaults
> - Thread Group
> -- HTTP Sampler (GET /foo)
> -- HTTP Sampler (GET /bar)
> -- HTTP Sampler (GET /baz)
>
> A couple of things that I have tried so far without luck:
> - Move the HTTP Request Defaults into the Thread Group and then
> surround with an If Controller. This causes the HTTP Requests Defaults
> to only be in the context of the If Controller now, and not propagated
> up the If Controller's parent.
> - Adding a BeanShell pre-processor to the Test Plan or Thread Group
> that will get the ThreadGroup from the current context and add a new
> Debug Sampler Element (would swap with ConfigTestElement later). That
> probably won't work in general since the structure of the test is
> already defined and not re-evaluated when I add the Test Element.
>
> Some things that will work, but I would like to avoid since they are
> not as sustainable:
> - Split into two separate scripts/thread groups, one with and one
> without the optional parameters.
> - Pass in another JMeter property for the parameter's key. The HTTP
> Requests Default would have an argument where name=${verboseKey} and
> value=${verboseValue}. If I wanted the parameter, I would have to set
> verboseKey="verboseLogs=" and verboseValue="true". This becomes hard
> to manage with many parameters.
>
> Any other ideas to try would be appreciated.
>
> Thanks.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
