On 14 December 2010 02:21, Anthony Johnson <[email protected]> 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 <[email protected]> wrote: >> On 14 December 2010 01:14, Anthony Johnson <[email protected]> wrote: >>> On Mon, Dec 13, 2010 at 4:21 PM, sebb <[email protected]> wrote: >>>> >>>> On 13 December 2010 20:38, Anthony Johnson <[email protected]> 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 <[email protected]> wrote: >>>> > >>>> >> On 13 December 2010 18:54, Anthony Johnson <[email protected]> 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: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
