You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@jmeter.apache.org by Anthony Johnson <an...@gmail.com> on 2010/12/13 19:54:49 UTC
JMeter Module + Include Controller limitation?
Hello list,
I am currently working on re-factoring a large number of JMeter test
plans which share quite a bit of logic. I've seen the ModuleController as a
way to re-use logic within a single Test Plan, but the ModuleController
doesn't seem to handle IncludeController files. I was hoping that the tree
within the Include would be visible as a selection for the ModuleController.
This doesn't happen.
My Goal was to have this:
+ <Disabled ThreadGroup>
-- Include common jmx file.
-- Include another_common jmx file
+ Thread Group
-- Module Controller -> Calling some tree in included file
Is an approach like this possible(and will work in non-GUI) without a code
change? We have been working around this so far with manual testplan merges
of update logic, but it ends up being very time consuming.
Thanks for your time,
Anthony
Re: JMeter Module + Include Controller limitation?
Posted by Ansgar Ruhnke <an...@googlemail.com>.
2010/12/13, Anthony Johnson <an...@gmail.com>:
> Hello list,
> I am currently working on re-factoring a large number of JMeter test
> plans which share quite a bit of logic. I've seen the ModuleController as a
> way to re-use logic within a single Test Plan, but the ModuleController
> doesn't seem to handle IncludeController files. I was hoping that the tree
> within the Include would be visible as a selection for the ModuleController.
>
> This doesn't happen.
>
> My Goal was to have this:
>
> + <Disabled ThreadGroup>
> -- Include common jmx file.
> -- Include another_common jmx file
> + Thread Group
> -- Module Controller -> Calling some tree in included file
>
>
> Is an approach like this possible(and will work in non-GUI) without a code
> change? We have been working around this so far with manual testplan merges
> of update logic, but it ends up being very time consuming.
>
> Thanks for your time,
>
> Anthony
>
--
Von meinen Mobilgerät aus gesendet
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: JMeter Module + Include Controller limitation?
Posted by sebb <se...@gmail.com>.
On 14 December 2010 02:21, Anthony Johnson <an...@gmail.com> wrote:
> A lot of quotes:-)
>
> Question: Would it make sense to introduce a new node-type called
> Test Fragment that could be placed immediately under the Test Plan
> element? It would be a non-executable ThreadGroup in a sense.
>
> The idea here is that it would make the Include Controller flow a
> little more elegant:
>
> 1. The idea of having a non-executable code section that the Module
> Element could reference without the need of a disabled ThreadGroup to
> accomplish the task.
> 2. The ability to have the Include file be a part of the actual Test
> Plan(Ctrl+S works)
> 3. Included files could also have a Thread Group as well that could
> be used for regression/testing.
>
> Thoughts? Sorry for turning this into a dev conversation.
Sounds interesting - I see you have already created a Bugzilla with
some patches.
We'll take a look shortly.
> Anthony
>
> On Mon, Dec 13, 2010 at 8:53 PM, sebb <se...@gmail.com> wrote:
>> On 14 December 2010 01:14, Anthony Johnson <an...@gmail.com> wrote:
>>> On Mon, Dec 13, 2010 at 4:21 PM, sebb <se...@gmail.com> wrote:
>>>>
>>>> On 13 December 2010 20:38, Anthony Johnson <an...@gmail.com> wrote:
>>>> > Problem mitigated. The Disabled ThreadGroup worked and I can execute an
>>>> > IncludeController operation multiple times via a ModuleController and it
>>>> > works as expected. I cannot dive into the IncludedFile from the
>>>> > ModuleController though which is not a showstopper.
>>>> >
>>>> > Problem was that I was accidentally saving the WorkBench as part of my
>>>> > include file.
>>>> >
>>>> > Some thoughts on this area of code that would make it a lot more awesome:
>>>> >
>>>> > 1. Editing Test Plan fragments is error-prone due to the Save operation
>>>> > only works on the Test Plan node. I would expect that the save operation
>>>> > would work successfully for my edited changes.
>>>>
>>>> Save and "Save Testplan As" do not include the WorkBench. This will
>>>> not be changed.
>>>>
>>>> Any node - including the WorkBench - can be saved using "Save Selection As".
>>>
>>> The problem is when you open one of the "Save Selection As" files, if
>>> the item is not part of a Test Plan or WorkBench then it is
>>> automatically appended to the WorkBench. At this point if the user
>>> does Ctrl+S, they overwrite their original with an empty test plan.
>>> This is a pretty bad flow.
>>
>> One solution would be to prevent Ctrl+S from working in this case.
>>
>> Should be easy enough to clear the current file name to stop Save from working.
>> But I've no idea how easy it would be to distinguish such partial files.
>>
>>>>
>>>> > -- Couldn't we just allow a SimpleController under the Test Plan
>>>>
>>>> I don't think that's possible without breaking lots of code.
>>>> Not sure it provides any benefit.
>>>
>>> It provides the benefit that I can save a Test Fragment in a more
>>> natural way instead of always having to highlight->"Save Selection As"
>>> every time I wish to save it.
>>
>> But it would not be a valid test plan.
>>
>> JMeter GUI tries to ensure that only valid plans can be created, as
>> far as possible.
>> So for example Post-Processors cannot have any child elements.
>>
>>>>
>>>> > object or fix the IncludeController to remove the ThreadGroup portion of the
>>>> > tree when importing?
>>>>
>>>> That might be possible.
>>>>
>>>> > 2. Show imported tree in Main Test Plan. Just so you can analyze without
>>>> > have to change context and change back.
>>>>
>>>> Why not just start another copy of JMeter?
>>>
>>> Good point:-)
>>>
>>>>
>>>> > 3. Inline editing of includes in the Main Test Plan. I personally hate
>>>> > having to completely change context to edit an Include file.
>>>>
>>>> Why not just start another copy of JMeter and keep it running for such changes?
>>>>
>>>> > 4. ModuleController support for executing different portions of an include
>>>> > file. This would allow for a single include file to act as a library
>>>> > offering up several "functions".
>>>>
>>>> I think that could be very tricky to implement.
>>>>
>>>> > I don't mind doing the code changes, I just don't want to step on toes or
>>>> > duplicate effort. Or... make a change that will never be merged.
>>>>
>>>> I think most of the changes would require a lot of work, both to
>>>> implement and to test and document.
>>>>
>>>> The Include and Module Controller code is quite tricky and not easy to
>>>> follow; it's very easy to break it.
>>>>
>>>> The only one that might be simpler is stripping the ThreadGroup out of
>>>> an Include file.
>>>>
>>>> If you can get that working, please create a Bugzilla issue and attach
>>>> the patch there.
>>>>
>>>> > Thanks for the quick responses,
>>>> >
>>>> > Anthony
>>>> >
>>>> > On Mon, Dec 13, 2010 at 2:32 PM, sebb <se...@gmail.com> wrote:
>>>> >
>>>> >> On 13 December 2010 18:54, Anthony Johnson <an...@gmail.com> wrote:
>>>> >> > Hello list,
>>>> >> > I am currently working on re-factoring a large number of JMeter test
>>>> >> > plans which share quite a bit of logic. I've seen the ModuleController
>>>> >> as a
>>>> >> > way to re-use logic within a single Test Plan, but the ModuleController
>>>> >> > doesn't seem to handle IncludeController files. I was hoping that the
>>>> >> tree
>>>> >> > within the Include would be visible as a selection for the
>>>> >> ModuleController.
>>>> >> >
>>>> >> > This doesn't happen.
>>>> >> >
>>>> >> > My Goal was to have this:
>>>> >> >
>>>> >> > + <Disabled ThreadGroup>
>>>> >> > -- Include common jmx file.
>>>> >> > -- Include another_common jmx file
>>>> >> > + Thread Group
>>>> >> > -- Module Controller -> Calling some tree in included file
>>>> >>
>>>> >> I suspect the problem may be due to the disabled parent - the Include
>>>> >> controller may need to run in order to resolve the includes.
>>>> >> Try enabling the thread group and see if that fixes it.
>>>> >>
>>>> >> >
>>>> >> > Is an approach like this possible(and will work in non-GUI) without a
>>>> >> code
>>>> >> > change? We have been working around this so far with manual testplan
>>>> >> merges
>>>> >> > of update logic, but it ends up being very time consuming.
>>>> >> >
>>>> >> > Thanks for your time,
>>>> >> >
>>>> >> > Anthony
>>
>> ---------------------------------------------------------------------
>> 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: JMeter Module + Include Controller limitation?
Posted by Anthony Johnson <an...@gmail.com>.
A lot of quotes:-)
Question: Would it make sense to introduce a new node-type called
Test Fragment that could be placed immediately under the Test Plan
element? It would be a non-executable ThreadGroup in a sense.
The idea here is that it would make the Include Controller flow a
little more elegant:
1. The idea of having a non-executable code section that the Module
Element could reference without the need of a disabled ThreadGroup to
accomplish the task.
2. The ability to have the Include file be a part of the actual Test
Plan(Ctrl+S works)
3. Included files could also have a Thread Group as well that could
be used for regression/testing.
Thoughts? Sorry for turning this into a dev conversation.
Anthony
On Mon, Dec 13, 2010 at 8:53 PM, sebb <se...@gmail.com> wrote:
> On 14 December 2010 01:14, Anthony Johnson <an...@gmail.com> wrote:
>> On Mon, Dec 13, 2010 at 4:21 PM, sebb <se...@gmail.com> wrote:
>>>
>>> On 13 December 2010 20:38, Anthony Johnson <an...@gmail.com> wrote:
>>> > Problem mitigated. The Disabled ThreadGroup worked and I can execute an
>>> > IncludeController operation multiple times via a ModuleController and it
>>> > works as expected. I cannot dive into the IncludedFile from the
>>> > ModuleController though which is not a showstopper.
>>> >
>>> > Problem was that I was accidentally saving the WorkBench as part of my
>>> > include file.
>>> >
>>> > Some thoughts on this area of code that would make it a lot more awesome:
>>> >
>>> > 1. Editing Test Plan fragments is error-prone due to the Save operation
>>> > only works on the Test Plan node. I would expect that the save operation
>>> > would work successfully for my edited changes.
>>>
>>> Save and "Save Testplan As" do not include the WorkBench. This will
>>> not be changed.
>>>
>>> Any node - including the WorkBench - can be saved using "Save Selection As".
>>
>> The problem is when you open one of the "Save Selection As" files, if
>> the item is not part of a Test Plan or WorkBench then it is
>> automatically appended to the WorkBench. At this point if the user
>> does Ctrl+S, they overwrite their original with an empty test plan.
>> This is a pretty bad flow.
>
> One solution would be to prevent Ctrl+S from working in this case.
>
> Should be easy enough to clear the current file name to stop Save from working.
> But I've no idea how easy it would be to distinguish such partial files.
>
>>>
>>> > -- Couldn't we just allow a SimpleController under the Test Plan
>>>
>>> I don't think that's possible without breaking lots of code.
>>> Not sure it provides any benefit.
>>
>> It provides the benefit that I can save a Test Fragment in a more
>> natural way instead of always having to highlight->"Save Selection As"
>> every time I wish to save it.
>
> But it would not be a valid test plan.
>
> JMeter GUI tries to ensure that only valid plans can be created, as
> far as possible.
> So for example Post-Processors cannot have any child elements.
>
>>>
>>> > object or fix the IncludeController to remove the ThreadGroup portion of the
>>> > tree when importing?
>>>
>>> That might be possible.
>>>
>>> > 2. Show imported tree in Main Test Plan. Just so you can analyze without
>>> > have to change context and change back.
>>>
>>> Why not just start another copy of JMeter?
>>
>> Good point:-)
>>
>>>
>>> > 3. Inline editing of includes in the Main Test Plan. I personally hate
>>> > having to completely change context to edit an Include file.
>>>
>>> Why not just start another copy of JMeter and keep it running for such changes?
>>>
>>> > 4. ModuleController support for executing different portions of an include
>>> > file. This would allow for a single include file to act as a library
>>> > offering up several "functions".
>>>
>>> I think that could be very tricky to implement.
>>>
>>> > I don't mind doing the code changes, I just don't want to step on toes or
>>> > duplicate effort. Or... make a change that will never be merged.
>>>
>>> I think most of the changes would require a lot of work, both to
>>> implement and to test and document.
>>>
>>> The Include and Module Controller code is quite tricky and not easy to
>>> follow; it's very easy to break it.
>>>
>>> The only one that might be simpler is stripping the ThreadGroup out of
>>> an Include file.
>>>
>>> If you can get that working, please create a Bugzilla issue and attach
>>> the patch there.
>>>
>>> > Thanks for the quick responses,
>>> >
>>> > Anthony
>>> >
>>> > On Mon, Dec 13, 2010 at 2:32 PM, sebb <se...@gmail.com> wrote:
>>> >
>>> >> On 13 December 2010 18:54, Anthony Johnson <an...@gmail.com> wrote:
>>> >> > Hello list,
>>> >> > I am currently working on re-factoring a large number of JMeter test
>>> >> > plans which share quite a bit of logic. I've seen the ModuleController
>>> >> as a
>>> >> > way to re-use logic within a single Test Plan, but the ModuleController
>>> >> > doesn't seem to handle IncludeController files. I was hoping that the
>>> >> tree
>>> >> > within the Include would be visible as a selection for the
>>> >> ModuleController.
>>> >> >
>>> >> > This doesn't happen.
>>> >> >
>>> >> > My Goal was to have this:
>>> >> >
>>> >> > + <Disabled ThreadGroup>
>>> >> > -- Include common jmx file.
>>> >> > -- Include another_common jmx file
>>> >> > + Thread Group
>>> >> > -- Module Controller -> Calling some tree in included file
>>> >>
>>> >> I suspect the problem may be due to the disabled parent - the Include
>>> >> controller may need to run in order to resolve the includes.
>>> >> Try enabling the thread group and see if that fixes it.
>>> >>
>>> >> >
>>> >> > Is an approach like this possible(and will work in non-GUI) without a
>>> >> code
>>> >> > change? We have been working around this so far with manual testplan
>>> >> merges
>>> >> > of update logic, but it ends up being very time consuming.
>>> >> >
>>> >> > Thanks for your time,
>>> >> >
>>> >> > Anthony
>
> ---------------------------------------------------------------------
> 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: JMeter Module + Include Controller limitation?
Posted by sebb <se...@gmail.com>.
On 14 December 2010 01:14, Anthony Johnson <an...@gmail.com> wrote:
> On Mon, Dec 13, 2010 at 4:21 PM, sebb <se...@gmail.com> wrote:
>>
>> On 13 December 2010 20:38, Anthony Johnson <an...@gmail.com> wrote:
>> > Problem mitigated. The Disabled ThreadGroup worked and I can execute an
>> > IncludeController operation multiple times via a ModuleController and it
>> > works as expected. I cannot dive into the IncludedFile from the
>> > ModuleController though which is not a showstopper.
>> >
>> > Problem was that I was accidentally saving the WorkBench as part of my
>> > include file.
>> >
>> > Some thoughts on this area of code that would make it a lot more awesome:
>> >
>> > 1. Editing Test Plan fragments is error-prone due to the Save operation
>> > only works on the Test Plan node. I would expect that the save operation
>> > would work successfully for my edited changes.
>>
>> Save and "Save Testplan As" do not include the WorkBench. This will
>> not be changed.
>>
>> Any node - including the WorkBench - can be saved using "Save Selection As".
>
> The problem is when you open one of the "Save Selection As" files, if
> the item is not part of a Test Plan or WorkBench then it is
> automatically appended to the WorkBench. At this point if the user
> does Ctrl+S, they overwrite their original with an empty test plan.
> This is a pretty bad flow.
One solution would be to prevent Ctrl+S from working in this case.
Should be easy enough to clear the current file name to stop Save from working.
But I've no idea how easy it would be to distinguish such partial files.
>>
>> > -- Couldn't we just allow a SimpleController under the Test Plan
>>
>> I don't think that's possible without breaking lots of code.
>> Not sure it provides any benefit.
>
> It provides the benefit that I can save a Test Fragment in a more
> natural way instead of always having to highlight->"Save Selection As"
> every time I wish to save it.
But it would not be a valid test plan.
JMeter GUI tries to ensure that only valid plans can be created, as
far as possible.
So for example Post-Processors cannot have any child elements.
>>
>> > object or fix the IncludeController to remove the ThreadGroup portion of the
>> > tree when importing?
>>
>> That might be possible.
>>
>> > 2. Show imported tree in Main Test Plan. Just so you can analyze without
>> > have to change context and change back.
>>
>> Why not just start another copy of JMeter?
>
> Good point:-)
>
>>
>> > 3. Inline editing of includes in the Main Test Plan. I personally hate
>> > having to completely change context to edit an Include file.
>>
>> Why not just start another copy of JMeter and keep it running for such changes?
>>
>> > 4. ModuleController support for executing different portions of an include
>> > file. This would allow for a single include file to act as a library
>> > offering up several "functions".
>>
>> I think that could be very tricky to implement.
>>
>> > I don't mind doing the code changes, I just don't want to step on toes or
>> > duplicate effort. Or... make a change that will never be merged.
>>
>> I think most of the changes would require a lot of work, both to
>> implement and to test and document.
>>
>> The Include and Module Controller code is quite tricky and not easy to
>> follow; it's very easy to break it.
>>
>> The only one that might be simpler is stripping the ThreadGroup out of
>> an Include file.
>>
>> If you can get that working, please create a Bugzilla issue and attach
>> the patch there.
>>
>> > Thanks for the quick responses,
>> >
>> > Anthony
>> >
>> > On Mon, Dec 13, 2010 at 2:32 PM, sebb <se...@gmail.com> wrote:
>> >
>> >> On 13 December 2010 18:54, Anthony Johnson <an...@gmail.com> wrote:
>> >> > Hello list,
>> >> > I am currently working on re-factoring a large number of JMeter test
>> >> > plans which share quite a bit of logic. I've seen the ModuleController
>> >> as a
>> >> > way to re-use logic within a single Test Plan, but the ModuleController
>> >> > doesn't seem to handle IncludeController files. I was hoping that the
>> >> tree
>> >> > within the Include would be visible as a selection for the
>> >> ModuleController.
>> >> >
>> >> > This doesn't happen.
>> >> >
>> >> > My Goal was to have this:
>> >> >
>> >> > + <Disabled ThreadGroup>
>> >> > -- Include common jmx file.
>> >> > -- Include another_common jmx file
>> >> > + Thread Group
>> >> > -- Module Controller -> Calling some tree in included file
>> >>
>> >> I suspect the problem may be due to the disabled parent - the Include
>> >> controller may need to run in order to resolve the includes.
>> >> Try enabling the thread group and see if that fixes it.
>> >>
>> >> >
>> >> > Is an approach like this possible(and will work in non-GUI) without a
>> >> code
>> >> > change? We have been working around this so far with manual testplan
>> >> merges
>> >> > of update logic, but it ends up being very time consuming.
>> >> >
>> >> > Thanks for your time,
>> >> >
>> >> > Anthony
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: JMeter Module + Include Controller limitation?
Posted by Anthony Johnson <an...@gmail.com>.
On Mon, Dec 13, 2010 at 4:21 PM, sebb <se...@gmail.com> wrote:
>
> On 13 December 2010 20:38, Anthony Johnson <an...@gmail.com> wrote:
> > Problem mitigated. The Disabled ThreadGroup worked and I can execute an
> > IncludeController operation multiple times via a ModuleController and it
> > works as expected. I cannot dive into the IncludedFile from the
> > ModuleController though which is not a showstopper.
> >
> > Problem was that I was accidentally saving the WorkBench as part of my
> > include file.
> >
> > Some thoughts on this area of code that would make it a lot more awesome:
> >
> > 1. Editing Test Plan fragments is error-prone due to the Save operation
> > only works on the Test Plan node. I would expect that the save operation
> > would work successfully for my edited changes.
>
> Save and "Save Testplan As" do not include the WorkBench. This will
> not be changed.
>
> Any node - including the WorkBench - can be saved using "Save Selection As".
The problem is when you open one of the "Save Selection As" files, if
the item is not part of a Test Plan or WorkBench then it is
automatically appended to the WorkBench. At this point if the user
does Ctrl+S, they overwrite their original with an empty test plan.
This is a pretty bad flow.
>
> > -- Couldn't we just allow a SimpleController under the Test Plan
>
> I don't think that's possible without breaking lots of code.
> Not sure it provides any benefit.
It provides the benefit that I can save a Test Fragment in a more
natural way instead of always having to highlight->"Save Selection As"
every time I wish to save it.
>
> > object or fix the IncludeController to remove the ThreadGroup portion of the
> > tree when importing?
>
> That might be possible.
>
> > 2. Show imported tree in Main Test Plan. Just so you can analyze without
> > have to change context and change back.
>
> Why not just start another copy of JMeter?
Good point:-)
>
> > 3. Inline editing of includes in the Main Test Plan. I personally hate
> > having to completely change context to edit an Include file.
>
> Why not just start another copy of JMeter and keep it running for such changes?
>
> > 4. ModuleController support for executing different portions of an include
> > file. This would allow for a single include file to act as a library
> > offering up several "functions".
>
> I think that could be very tricky to implement.
>
> > I don't mind doing the code changes, I just don't want to step on toes or
> > duplicate effort. Or... make a change that will never be merged.
>
> I think most of the changes would require a lot of work, both to
> implement and to test and document.
>
> The Include and Module Controller code is quite tricky and not easy to
> follow; it's very easy to break it.
>
> The only one that might be simpler is stripping the ThreadGroup out of
> an Include file.
>
> If you can get that working, please create a Bugzilla issue and attach
> the patch there.
>
> > Thanks for the quick responses,
> >
> > Anthony
> >
> > On Mon, Dec 13, 2010 at 2:32 PM, sebb <se...@gmail.com> wrote:
> >
> >> On 13 December 2010 18:54, Anthony Johnson <an...@gmail.com> wrote:
> >> > Hello list,
> >> > I am currently working on re-factoring a large number of JMeter test
> >> > plans which share quite a bit of logic. I've seen the ModuleController
> >> as a
> >> > way to re-use logic within a single Test Plan, but the ModuleController
> >> > doesn't seem to handle IncludeController files. I was hoping that the
> >> tree
> >> > within the Include would be visible as a selection for the
> >> ModuleController.
> >> >
> >> > This doesn't happen.
> >> >
> >> > My Goal was to have this:
> >> >
> >> > + <Disabled ThreadGroup>
> >> > -- Include common jmx file.
> >> > -- Include another_common jmx file
> >> > + Thread Group
> >> > -- Module Controller -> Calling some tree in included file
> >>
> >> I suspect the problem may be due to the disabled parent - the Include
> >> controller may need to run in order to resolve the includes.
> >> Try enabling the thread group and see if that fixes it.
> >>
> >> >
> >> > Is an approach like this possible(and will work in non-GUI) without a
> >> code
> >> > change? We have been working around this so far with manual testplan
> >> merges
> >> > of update logic, but it ends up being very time consuming.
> >> >
> >> > Thanks for your time,
> >> >
> >> > Anthony
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> 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: JMeter Module + Include Controller limitation?
Posted by sebb <se...@gmail.com>.
On 13 December 2010 20:38, Anthony Johnson <an...@gmail.com> wrote:
> Problem mitigated. The Disabled ThreadGroup worked and I can execute an
> IncludeController operation multiple times via a ModuleController and it
> works as expected. I cannot dive into the IncludedFile from the
> ModuleController though which is not a showstopper.
>
> Problem was that I was accidentally saving the WorkBench as part of my
> include file.
>
> Some thoughts on this area of code that would make it a lot more awesome:
>
> 1. Editing Test Plan fragments is error-prone due to the Save operation
> only works on the Test Plan node. I would expect that the save operation
> would work successfully for my edited changes.
Save and "Save Testplan As" do not include the WorkBench. This will
not be changed.
Any node - including the WorkBench - can be saved using "Save Selection As".
> -- Couldn't we just allow a SimpleController under the Test Plan
I don't think that's possible without breaking lots of code.
Not sure it provides any benefit.
> object or fix the IncludeController to remove the ThreadGroup portion of the
> tree when importing?
That might be possible.
> 2. Show imported tree in Main Test Plan. Just so you can analyze without
> have to change context and change back.
Why not just start another copy of JMeter?
> 3. Inline editing of includes in the Main Test Plan. I personally hate
> having to completely change context to edit an Include file.
Why not just start another copy of JMeter and keep it running for such changes?
> 4. ModuleController support for executing different portions of an include
> file. This would allow for a single include file to act as a library
> offering up several "functions".
I think that could be very tricky to implement.
> I don't mind doing the code changes, I just don't want to step on toes or
> duplicate effort. Or... make a change that will never be merged.
I think most of the changes would require a lot of work, both to
implement and to test and document.
The Include and Module Controller code is quite tricky and not easy to
follow; it's very easy to break it.
The only one that might be simpler is stripping the ThreadGroup out of
an Include file.
If you can get that working, please create a Bugzilla issue and attach
the patch there.
> Thanks for the quick responses,
>
> Anthony
>
> On Mon, Dec 13, 2010 at 2:32 PM, sebb <se...@gmail.com> wrote:
>
>> On 13 December 2010 18:54, Anthony Johnson <an...@gmail.com> wrote:
>> > Hello list,
>> > I am currently working on re-factoring a large number of JMeter test
>> > plans which share quite a bit of logic. I've seen the ModuleController
>> as a
>> > way to re-use logic within a single Test Plan, but the ModuleController
>> > doesn't seem to handle IncludeController files. I was hoping that the
>> tree
>> > within the Include would be visible as a selection for the
>> ModuleController.
>> >
>> > This doesn't happen.
>> >
>> > My Goal was to have this:
>> >
>> > + <Disabled ThreadGroup>
>> > -- Include common jmx file.
>> > -- Include another_common jmx file
>> > + Thread Group
>> > -- Module Controller -> Calling some tree in included file
>>
>> I suspect the problem may be due to the disabled parent - the Include
>> controller may need to run in order to resolve the includes.
>> Try enabling the thread group and see if that fixes it.
>>
>> >
>> > Is an approach like this possible(and will work in non-GUI) without a
>> code
>> > change? We have been working around this so far with manual testplan
>> merges
>> > of update logic, but it ends up being very time consuming.
>> >
>> > Thanks for your time,
>> >
>> > Anthony
>> >
>>
>> ---------------------------------------------------------------------
>> 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: JMeter Module + Include Controller limitation?
Posted by Anthony Johnson <an...@gmail.com>.
Problem mitigated. The Disabled ThreadGroup worked and I can execute an
IncludeController operation multiple times via a ModuleController and it
works as expected. I cannot dive into the IncludedFile from the
ModuleController though which is not a showstopper.
Problem was that I was accidentally saving the WorkBench as part of my
include file.
Some thoughts on this area of code that would make it a lot more awesome:
1. Editing Test Plan fragments is error-prone due to the Save operation
only works on the Test Plan node. I would expect that the save operation
would work successfully for my edited changes.
-- Couldn't we just allow a SimpleController under the Test Plan
object or fix the IncludeController to remove the ThreadGroup portion of the
tree when importing?
2. Show imported tree in Main Test Plan. Just so you can analyze without
have to change context and change back.
3. Inline editing of includes in the Main Test Plan. I personally hate
having to completely change context to edit an Include file.
4. ModuleController support for executing different portions of an include
file. This would allow for a single include file to act as a library
offering up several "functions".
I don't mind doing the code changes, I just don't want to step on toes or
duplicate effort. Or... make a change that will never be merged.
Thanks for the quick responses,
Anthony
On Mon, Dec 13, 2010 at 2:32 PM, sebb <se...@gmail.com> wrote:
> On 13 December 2010 18:54, Anthony Johnson <an...@gmail.com> wrote:
> > Hello list,
> > I am currently working on re-factoring a large number of JMeter test
> > plans which share quite a bit of logic. I've seen the ModuleController
> as a
> > way to re-use logic within a single Test Plan, but the ModuleController
> > doesn't seem to handle IncludeController files. I was hoping that the
> tree
> > within the Include would be visible as a selection for the
> ModuleController.
> >
> > This doesn't happen.
> >
> > My Goal was to have this:
> >
> > + <Disabled ThreadGroup>
> > -- Include common jmx file.
> > -- Include another_common jmx file
> > + Thread Group
> > -- Module Controller -> Calling some tree in included file
>
> I suspect the problem may be due to the disabled parent - the Include
> controller may need to run in order to resolve the includes.
> Try enabling the thread group and see if that fixes it.
>
> >
> > Is an approach like this possible(and will work in non-GUI) without a
> code
> > change? We have been working around this so far with manual testplan
> merges
> > of update logic, but it ends up being very time consuming.
> >
> > Thanks for your time,
> >
> > Anthony
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>
Re: JMeter Module + Include Controller limitation?
Posted by sebb <se...@gmail.com>.
On 13 December 2010 18:54, Anthony Johnson <an...@gmail.com> wrote:
> Hello list,
> I am currently working on re-factoring a large number of JMeter test
> plans which share quite a bit of logic. I've seen the ModuleController as a
> way to re-use logic within a single Test Plan, but the ModuleController
> doesn't seem to handle IncludeController files. I was hoping that the tree
> within the Include would be visible as a selection for the ModuleController.
>
> This doesn't happen.
>
> My Goal was to have this:
>
> + <Disabled ThreadGroup>
> -- Include common jmx file.
> -- Include another_common jmx file
> + Thread Group
> -- Module Controller -> Calling some tree in included file
I suspect the problem may be due to the disabled parent - the Include
controller may need to run in order to resolve the includes.
Try enabling the thread group and see if that fixes it.
>
> Is an approach like this possible(and will work in non-GUI) without a code
> change? We have been working around this so far with manual testplan merges
> of update logic, but it ends up being very time consuming.
>
> Thanks for your time,
>
> Anthony
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org