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