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. > > > -- 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 <[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]
