jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anthony Johnson <ans...@gmail.com>
Subject Re: JMeter Module + Include Controller limitation?
Date Tue, 14 Dec 2010 02:21:07 GMT
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 <sebbaz@gmail.com> wrote:
> On 14 December 2010 01:14, Anthony Johnson <ansoni@gmail.com> wrote:
>> On Mon, Dec 13, 2010 at 4:21 PM, sebb <sebbaz@gmail.com> wrote:
>>>
>>> On 13 December 2010 20:38, Anthony Johnson <ansoni@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 <sebbaz@gmail.com> wrote:
>>> >
>>> >> On 13 December 2010 18:54, Anthony Johnson <ansoni@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


Mime
View raw message