You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@jmeter.apache.org by Alexander Wallace <aw...@rwmotloc.com> on 2007/01/23 21:38:05 UTC
test plan scoped counter.
Hi All ...
My need is to have a few samplers in a thread group execute only
sometimes ( i can use a random condition here) but only for a
percentage of the threads .
My plan was to use a counter at the test plan level that when one
thread which randomly was selected executed, would increase the counter.
The problem I'm seeing is that defining a var at the test plan resets
the value for every thread.
Is there a way to have a variable to be referenced from any thread
and have the same value for all?
I realize there may be other ways to do what I'm requiring, but it
still sounds reasonable to have a variable that can be referenced
from any and all threads. I'm sure there is...
Thanks a lot for your help!
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: JUnit setUp() trap
Posted by Peter Lin <wo...@gmail.com>.
thanks for checking that. I will update the docs tonight.
again, sorry about that. I just assumed people would make setUp/tearDown
public. it never occurred to me people might make it protected or private
peter
On 1/23/07, Jürgen Weber <jw...@jwi.de> wrote:
>
> Actually, the tutorial
> (http://jakarta.apache.org/jmeter/usermanual/junitsampler_tutorial.pdf)
> does not mention that setUp() has to be public.
>
> OK, I entered http://issues.apache.org/bugzilla/show_bug.cgi?id=41446
>
> Debugging was actually a bit difficult as I could not simply run jmeter
> as part of my Eclipse project as jmeter does some magic loading its
> classes so I had to remote debug.
> But never mind, I learned something ;-)
>
> Thanks for a great tool,
> Jürgen
>
> Peter Lin wrote:
> > the tutorial on the JUnit sampler states the setup and teardown method
> > need
> > to be public. please open a bugzilla to enhance the user manual.
> >
> > sorry you had to waste time debugging your test. it's generally better
> to
> > make the setup, teardown, onetimesetup and onetimeteardown public
> > methods.
> >
> > peter
> >
> > On 1/23/07, Jürgen Weber <jw...@jwi.de> wrote:
> >>
> >> Hi,
> >>
> >> several JUnit tutorials (inclusive the sample at
> >> http://junit.sourceforge.net/javadoc/junit/framework/TestCase.html)
> >> show a
> >>
> >> protected void setUp()
> >>
> >> method.
> >>
> >>
> >> The JUnitSampler looks for the setUp() method using getMethod() but
> this
> >> finds only __public__ methods. So when you have a protected setUp() in
> >> your testcase, JUnitSampler will almost silently not call it, there is
> >> only a harmless log line:
> >>
> >> 2007/01/23 13:18:11 WARN - jmeter.protocol.java.sampler.JUnitSampler:
> >> unittest.UnitTestClientImpl.setUp()
> >>
> >> try {
> >> return clazz.getClass().getMethod(method,new Class[0]);
> >> } catch (NoSuchMethodException e) {
> >> log.warn(e.getMessage());
> >> }
> >>
> >> I think it were better if there was a [x] call setUp() and tearDown()
> on
> >> the gui and throw an exception if there is none or not found.
> >>
> >> It cost me quite some time and remote debugging to find out, why my
> >> setUp() was not called.
> >>
> >> Jürgen
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
> >>
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>
Re: JUnit setUp() trap
Posted by Peter Lin <wo...@gmail.com>.
I've updated the tutorial with a warning. thanks for catching that and
opening a bugzilla.
peter
On 1/23/07, Jürgen Weber <jw...@jwi.de> wrote:
>
> Actually, the tutorial
> (http://jakarta.apache.org/jmeter/usermanual/junitsampler_tutorial.pdf)
> does not mention that setUp() has to be public.
>
> OK, I entered http://issues.apache.org/bugzilla/show_bug.cgi?id=41446
>
> Debugging was actually a bit difficult as I could not simply run jmeter
> as part of my Eclipse project as jmeter does some magic loading its
> classes so I had to remote debug.
> But never mind, I learned something ;-)
>
> Thanks for a great tool,
> Jürgen
>
> Peter Lin wrote:
> > the tutorial on the JUnit sampler states the setup and teardown method
> > need
> > to be public. please open a bugzilla to enhance the user manual.
> >
> > sorry you had to waste time debugging your test. it's generally better
> to
> > make the setup, teardown, onetimesetup and onetimeteardown public
> > methods.
> >
> > peter
> >
> > On 1/23/07, Jürgen Weber <jw...@jwi.de> wrote:
> >>
> >> Hi,
> >>
> >> several JUnit tutorials (inclusive the sample at
> >> http://junit.sourceforge.net/javadoc/junit/framework/TestCase.html)
> >> show a
> >>
> >> protected void setUp()
> >>
> >> method.
> >>
> >>
> >> The JUnitSampler looks for the setUp() method using getMethod() but
> this
> >> finds only __public__ methods. So when you have a protected setUp() in
> >> your testcase, JUnitSampler will almost silently not call it, there is
> >> only a harmless log line:
> >>
> >> 2007/01/23 13:18:11 WARN - jmeter.protocol.java.sampler.JUnitSampler:
> >> unittest.UnitTestClientImpl.setUp()
> >>
> >> try {
> >> return clazz.getClass().getMethod(method,new Class[0]);
> >> } catch (NoSuchMethodException e) {
> >> log.warn(e.getMessage());
> >> }
> >>
> >> I think it were better if there was a [x] call setUp() and tearDown()
> on
> >> the gui and throw an exception if there is none or not found.
> >>
> >> It cost me quite some time and remote debugging to find out, why my
> >> setUp() was not called.
> >>
> >> Jürgen
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
> >>
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>
Re: JUnit setUp() trap
Posted by Jürgen Weber <jw...@jwi.de>.
Actually, the tutorial
(http://jakarta.apache.org/jmeter/usermanual/junitsampler_tutorial.pdf)
does not mention that setUp() has to be public.
OK, I entered http://issues.apache.org/bugzilla/show_bug.cgi?id=41446
Debugging was actually a bit difficult as I could not simply run jmeter
as part of my Eclipse project as jmeter does some magic loading its
classes so I had to remote debug.
But never mind, I learned something ;-)
Thanks for a great tool,
Jürgen
Peter Lin wrote:
> the tutorial on the JUnit sampler states the setup and teardown method
> need
> to be public. please open a bugzilla to enhance the user manual.
>
> sorry you had to waste time debugging your test. it's generally better to
> make the setup, teardown, onetimesetup and onetimeteardown public
> methods.
>
> peter
>
> On 1/23/07, Jürgen Weber <jw...@jwi.de> wrote:
>>
>> Hi,
>>
>> several JUnit tutorials (inclusive the sample at
>> http://junit.sourceforge.net/javadoc/junit/framework/TestCase.html)
>> show a
>>
>> protected void setUp()
>>
>> method.
>>
>>
>> The JUnitSampler looks for the setUp() method using getMethod() but this
>> finds only __public__ methods. So when you have a protected setUp() in
>> your testcase, JUnitSampler will almost silently not call it, there is
>> only a harmless log line:
>>
>> 2007/01/23 13:18:11 WARN - jmeter.protocol.java.sampler.JUnitSampler:
>> unittest.UnitTestClientImpl.setUp()
>>
>> try {
>> return clazz.getClass().getMethod(method,new Class[0]);
>> } catch (NoSuchMethodException e) {
>> log.warn(e.getMessage());
>> }
>>
>> I think it were better if there was a [x] call setUp() and tearDown() on
>> the gui and throw an exception if there is none or not found.
>>
>> It cost me quite some time and remote debugging to find out, why my
>> setUp() was not called.
>>
>> Jürgen
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: JUnit setUp() trap
Posted by Peter Lin <wo...@gmail.com>.
the tutorial on the JUnit sampler states the setup and teardown method need
to be public. please open a bugzilla to enhance the user manual.
sorry you had to waste time debugging your test. it's generally better to
make the setup, teardown, onetimesetup and onetimeteardown public methods.
peter
On 1/23/07, Jürgen Weber <jw...@jwi.de> wrote:
>
> Hi,
>
> several JUnit tutorials (inclusive the sample at
> http://junit.sourceforge.net/javadoc/junit/framework/TestCase.html) show a
>
> protected void setUp()
>
> method.
>
>
> The JUnitSampler looks for the setUp() method using getMethod() but this
> finds only __public__ methods. So when you have a protected setUp() in
> your testcase, JUnitSampler will almost silently not call it, there is
> only a harmless log line:
>
> 2007/01/23 13:18:11 WARN - jmeter.protocol.java.sampler.JUnitSampler:
> unittest.UnitTestClientImpl.setUp()
>
> try {
> return clazz.getClass().getMethod(method,new Class[0]);
> } catch (NoSuchMethodException e) {
> log.warn(e.getMessage());
> }
>
> I think it were better if there was a [x] call setUp() and tearDown() on
> the gui and throw an exception if there is none or not found.
>
> It cost me quite some time and remote debugging to find out, why my
> setUp() was not called.
>
> Jürgen
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>
JUnit setUp() trap
Posted by Jürgen Weber <jw...@jwi.de>.
Hi,
several JUnit tutorials (inclusive the sample at
http://junit.sourceforge.net/javadoc/junit/framework/TestCase.html) show a
protected void setUp()
method.
The JUnitSampler looks for the setUp() method using getMethod() but this
finds only __public__ methods. So when you have a protected setUp() in
your testcase, JUnitSampler will almost silently not call it, there is
only a harmless log line:
2007/01/23 13:18:11 WARN - jmeter.protocol.java.sampler.JUnitSampler:
unittest.UnitTestClientImpl.setUp()
try {
return clazz.getClass().getMethod(method,new Class[0]);
} catch (NoSuchMethodException e) {
log.warn(e.getMessage());
}
I think it were better if there was a [x] call setUp() and tearDown() on
the gui and throw an exception if there is none or not found.
It cost me quite some time and remote debugging to find out, why my
setUp() was not called.
Jürgen
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: test plan scoped counter.
Posted by Alexander Wallace <aw...@rwmotloc.com>.
I see... thank you very much!
On Jan 23, 2007, at 4:10 PM, sebb wrote:
> Properties can be accessed from all threads.
>
> Beware that changing them frequently may give errors or cause the
> threads to block each other...
>
> Variables are deliberately thread-specific.
>
> On 23/01/07, Alexander Wallace <aw...@rwmotloc.com> wrote:
>> Hi All ...
>>
>> My need is to have a few samplers in a thread group execute only
>> sometimes ( i can use a random condition here) but only for a
>> percentage of the threads .
>>
>> My plan was to use a counter at the test plan level that when one
>> thread which randomly was selected executed, would increase the
>> counter.
>>
>> The problem I'm seeing is that defining a var at the test plan resets
>> the value for every thread.
>>
>> Is there a way to have a variable to be referenced from any thread
>> and have the same value for all?
>>
>> I realize there may be other ways to do what I'm requiring, but it
>> still sounds reasonable to have a variable that can be referenced
>> from any and all threads. I'm sure there is...
>>
>> Thanks a lot for your help!
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: test plan scoped counter.
Posted by sebb <se...@gmail.com>.
Properties can be accessed from all threads.
Beware that changing them frequently may give errors or cause the
threads to block each other...
Variables are deliberately thread-specific.
On 23/01/07, Alexander Wallace <aw...@rwmotloc.com> wrote:
> Hi All ...
>
> My need is to have a few samplers in a thread group execute only
> sometimes ( i can use a random condition here) but only for a
> percentage of the threads .
>
> My plan was to use a counter at the test plan level that when one
> thread which randomly was selected executed, would increase the counter.
>
> The problem I'm seeing is that defining a var at the test plan resets
> the value for every thread.
>
> Is there a way to have a variable to be referenced from any thread
> and have the same value for all?
>
> I realize there may be other ways to do what I'm requiring, but it
> still sounds reasonable to have a variable that can be referenced
> from any and all threads. I'm sure there is...
>
> Thanks a lot for your help!
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org