@Deepak
Thanks for the suggestion. I tried it out, and that method did work.
Since there can be many samplers in the test, I would rather not have
to duplicate the pre-processors over and over again. Hence wanting to
get it working in the Defaults element.
@Oliver
That is a clever way of handling it. I hadn't thought of constructing
the whole optional part of the query string. Yes, the parameters can
be more than just Boolean values (probably a bad example), so I worked
off your suggestion and got things working. What I ended up doing is
kinda strange, and looks ugly, bug it keeps all the optional
parameters in one place.
Inside the Test Plan element, I set up a variable
optionalParameters=${__P(optionalParameters, false)} and also a
variable that was verboseLogs=${__P(verboseLogs, true)}. Inside my
HTTP Request Defaults was where the cool stuff happens. I added a
parameter with the name being ${__BeanShell( if (
vars.get("optionalParameters").toString().equalsIgnoreCase("true") )
return "verboseLogs"; )} and the value being ${__BeanShell( if (
vars.get("optionalParameters").toString().equalsIgnoreCase("true") )
return vars.get("verboseLogs"); )}. Basically if
optionalParameters=true, then make a parameter
verboseLogs=${verboseLogs}. Otherwise, both sides will be an empty
string and JMeter will ignore it.
What I like about keeping that in the HTTP Request Defaults is that I
can leverage the encode logic from JMeter (instead of recreating it
outside and passing it into the script). I also get to use these
optional variables in multipart/form POST requests without any other
changes. It seems excessive to have to check the ${optionalParameters}
value over and over, but I guess it works, so I should be happy!
Thanks!
On Thu, Aug 2, 2012 at 4:28 PM, Deepak Shetty <[email protected]> wrote:
> Hi
>>Is there a way to modify that test element dynamically during the test
> execution?
> A beanShell preprocessor can access the HTTPSampler - and should be able to
> remove arguments on the fly (but I havent tested it) - and how you identify
> what it is to be removed is upto you
> Alternately don't use request defaults and use the preprocessor to add
> arguments dynamically (and how you determine what to add is your code) .e.g
> http://theworkaholic.blogspot.com/2010/03/dynamic-parameters-in-jmeter.html
>
> regards
> deepak
>
> On Thu, Aug 2, 2012 at 4:01 PM, Stephen Ash <[email protected]> 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]
