headers
Stephen Ash | 3 Aug 2012 01:01
Picon

Dynamically enable/disable HTTP Request Defaults parameters

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:
(Continue reading)

Permalink | Reply |
headers
Oliver Lloyd | 3 Aug 2012 01:19
Picon
Favicon

Re: Dynamically enable/disable HTTP Request Defaults parameters

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)
(Continue reading)

Permalink | Reply |
headers
Deepak Shetty | 3 Aug 2012 01:28
Picon

Re: Dynamically enable/disable HTTP Request Defaults parameters

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 <stephenash <at> gmail.com> 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)
(Continue reading)

Permalink | Reply |
headers
Stephen Ash | 3 Aug 2012 03:55
Picon

Re: Dynamically enable/disable HTTP Request Defaults parameters

 <at> 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.

 <at> 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
(Continue reading)

Permalink | Reply |
headers
Deepak Shetty | 3 Aug 2012 04:57
Picon

Re: Dynamically enable/disable HTTP Request Defaults parameters

>I would rather not have to duplicate the pre-processors over and over
again.
If you create the pre processor under the thread group then it applies to
all samplers (just like the defaults element)

On Thu, Aug 2, 2012 at 6:55 PM, Stephen Ash <stephenash <at> gmail.com> wrote:

>  <at> 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.
>
>  <at> 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
(Continue reading)

Permalink | Reply |
headers
madhu sekhar | 3 Aug 2012 05:07
Picon

Re: Dynamically enable/disable HTTP Request Defaults parameters

 <at> Deepak, Can you please explain how to use beanshell preprocessor to
capture values from java script?

On Fri, Aug 3, 2012 at 8:27 AM, Deepak Shetty <shettyd <at> gmail.com> wrote:

> >I would rather not have to duplicate the pre-processors over and over
> again.
> If you create the pre processor under the thread group then it applies to
> all samplers (just like the defaults element)
>
> On Thu, Aug 2, 2012 at 6:55 PM, Stephen Ash <stephenash <at> gmail.com> wrote:
>
> >  <at> 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.
> >
> >  <at> 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
(Continue reading)

Permalink | Reply |
headers
Deepak Shetty | 3 Aug 2012 05:08
Picon

Re: Dynamically enable/disable HTTP Request Defaults parameters

please use a different thread for a different issue

On Thu, Aug 2, 2012 at 8:07 PM, madhu sekhar <madhuvchandana <at> gmail.com>wrote:

>  <at> Deepak, Can you please explain how to use beanshell preprocessor to
> capture values from java script?
>
> On Fri, Aug 3, 2012 at 8:27 AM, Deepak Shetty <shettyd <at> gmail.com> wrote:
>
> > >I would rather not have to duplicate the pre-processors over and over
> > again.
> > If you create the pre processor under the thread group then it applies to
> > all samplers (just like the defaults element)
> >
> > On Thu, Aug 2, 2012 at 6:55 PM, Stephen Ash <stephenash <at> gmail.com>
> wrote:
> >
> > >  <at> 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.
> > >
> > >  <at> 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.
(Continue reading)

Permalink | Reply |

Gmane