Mailing-List: contact jmeter-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "JMeter Users List" <jmeter-user@jakarta.apache.org>
Received-SPF: pass (athena.apache.org: domain of ansoni@gmail.com designates
 74.125.83.42 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=Wxnl8f7mdtyFRg5DAH8z42hX7OvbW5Wpnsv/ZhXAAMU3vo2ffX/zKrt6rzvplztsgo
         V7Fs9+MhMd3Yljqj7evPWuMoSjvodhedh3xNbuVjGgkPpFy2WI/mYmInJEoVPc8N/9Io
         ulqxt1P2i+Pb++5Eq7+bwz+zguN2XkRYOIXs0=
MIME-Version: 1.0
In-Reply-To: <AANLkTi=KJ-NwgyS6pSqkFXwyKGUruH5gRh8AUinZPzWq@mail.gmail.com>
References: <AANLkTinPZyE=+S4MUxf-5yMY9N969EP2FRFo+gdPghi6@mail.gmail.com>
	<AANLkTi=9rUOK4FpvWRSafxc__M4QpnZZzDcDghfy0Wus@mail.gmail.com>
	<AANLkTi=+hZstt-52L_pJiqszMLqdHK5e4CQ+OPqJu+cc@mail.gmail.com>
	<AANLkTinKsY1NecwKFZpjA_myCAESbXC8bQLtti=a_w6H@mail.gmail.com>
	<AANLkTin_9gwCjuQnGGdMSB5LDO9Y8dfKyWG2iGyn+NDB@mail.gmail.com>
	<AANLkTi=KJ-NwgyS6pSqkFXwyKGUruH5gRh8AUinZPzWq@mail.gmail.com>
Date: Mon, 13 Dec 2010 21:21:07 -0500
Message-ID: <AANLkTikcRzs+caFLMLL5c8iU23NPO2=ebdmXpqWaVZoG@mail.gmail.com>
Subject: Re: JMeter Module + Include Controller limitation?
From: Anthony Johnson <ansoni@gmail.com>
To: JMeter Users List <jmeter-user@jakarta.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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. =A0The Disabled ThreadGroup worked and I can execu=
te an
>>> > IncludeController operation multiple times via a ModuleController and=
 it
>>> > works as expected. =A0I 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 m=
y
>>> > include file.
>>> >
>>> > Some thoughts on this area of code that would make it a lot more awes=
ome:
>>> >
>>> > 1. =A0Editing Test Plan fragments is error-prone due to the Save oper=
ation
>>> > only works on the Test Plan node. =A0I would expect that the save ope=
ration
>>> > 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. =A0At 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 wo=
rking.
> But I've no idea how easy it would be to distinguish such partial files.
>
>>>
>>> > =A0 =A0 =A0-- Couldn't we just allow a SimpleController under the Tes=
t 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. =A0Show imported tree in Main Test Plan. =A0Just so you can analyz=
e without
>>> > have to change context and change back.
>>>
>>> Why not just start another copy of JMeter?
>>
>> Good point:-)
>>
>>>
>>> > 3. =A0Inline editing of includes in the Main Test Plan. =A0I personal=
ly 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. =A0ModuleController support for executing different portions of an=
 include
>>> > file. =A0This would allow for a single include file to act as a libra=
ry
>>> > 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 toe=
s or
>>> > duplicate effort. =A0Or... 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,
>>> >> > =A0 =A0I am currently working on re-factoring a large number of JM=
eter test
>>> >> > plans which share quite a bit of logic. =A0I've seen the ModuleCon=
troller
>>> >> as a
>>> >> > way to re-use logic within a single Test Plan, but the ModuleContr=
oller
>>> >> > doesn't seem to handle IncludeController files. =A0I was hoping th=
at 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>
>>> >> > =A0 -- Include common jmx file.
>>> >> > =A0 -- Include another_common jmx file
>>> >> > + Thread Group
>>> >> > =A0 -- Module Controller -> Calling some tree in included file
>>> >>
>>> >> I suspect the problem may be due to the disabled parent - the Includ=
e
>>> >> 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) withou=
t a
>>> >> code
>>> >> > change? =A0We have been working around this so far with manual tes=
tplan
>>> >> 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