You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jmeter-dev@jakarta.apache.org by Mike Stover <ms...@apache.org> on 2003/02/03 17:14:51 UTC
Modified test tree
Ok folks, 1.8.1 is out of the way (I'll be making a src release file too, later). I've
just committed my changes to make the test tree hold TestElement objects instead
of GUI objects.
It was both easier and harder than I thought it would be originally. Please check it
out and put it through it's paces. I think I touched all the important points, but we
need to be sure. One thing though, it is much faster loading big test plans :-)
--
Michael Stover
mstover1@apache.org
Yahoo IM: mstover_ya
ICQ: 152975688
AIM: mstover777
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: Modified test tree
Posted by Mike Stover <ms...@apache.org>.
On 4 Feb 2003 at 21:13, Oliver Rossmueller wrote:
> [snip]
> The factory is not the key point, the key point is that I would like to
> have a clean separation of GUI and test elements. Then for example I
> could create a command line tool to record test plans and use the same
> functionality to create test elements that is used by the GUI. And I
> could run this recorder on a linux box without X-Windows because the GUI
> would not be used in that case. This is not possible at the moment.
>
Well, I finally understand why this is a problem for you. So, I started a wiki page about it.
http://nagoya.apache.org/wiki/apachewiki.cgi?JMeterGuiTestElementSeparation
-Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: Modified test tree
Posted by Oliver Rossmueller <ol...@tuxerra.com>.
Mike Stover wrote:
> On 4 Feb 2003 at 0:15, Oliver Rossmueller wrote:
>
>
>>No, one factory to create all of them. In fact it is just
>>Class.forName(elementClassName).newInstance(). Filling the properties
>>with default values should not be done by the GUI but in the element's
>>constructor. So the only property the test element constructor can not
>>set is the gui class name. But the test element should not know about
>>GUIs anyway so I don't see the need to hold the name of the
>>corresponding GUI class in the test element's properties. There are
>>other ways to assign GUIs to test elements (e.g. ask the GUI which kind
>>of test elements it can handle and then select the right one) and to
>>keep separation of concerns. The test elements are the model and should
>>not know about the very existence of a GUI.
>
>
> Couple things. One, I'd like to avoid a 1:1 mapping of testelements to gui classes.
> Right now, 5 guis can serve the same test element, and that's a nice feature. It
> means I can make a different gui for the HTTP Sampler if I want, and the only thing
> I have to write is the GUI - I don't have to make a new copy of the HTTPSampler
> class.
I think you are talking about the request defaults elements which are
all instances of ConfigTestElement but use different GUIs. I don't know
why it is done this way - I thought this was some kind of copy&paste bug
- because there are special classes in the code base for all the
defaults but they are not used. I don't see any use of having two
different GUIs for HTTPSampler to stay with your example. And how will
JMeter decide which one to use?
> Two, related to that is that the GUI's are the authorities on how to initiate test
> element's and their data - because they fully control the data that goes into them
> anyway.
Well, the GUI fill the test elements with data, but the test elements
have to control if the values set by the GUI are valid and correct. They
don't do this at the moment but IMHO they have to because they rely on
correct data when executing the tests. And there is another way to fill
test elements with data by loading a jmx file, and this should not go
through the GUI.
> Three, the gui class is saved in the test element so that when test plans are
> reloaded, JMeter knows which gui goes with it. Otherwise, you need that 1:1
> mapping to figure it out, plus that would be slower, as JMeter would have to search
> through all the gui classes to find the right one.
It is not hard to create a map holding the required information e.g.
when searching for the classes at startup.
> As far as I'm concerned, the separation of concerns is not violated by the
> testelement holding gui related data. As long as the code is completely ignorant,
> I'm not worried about what data the gui's stuff in them.
Ok.
> I noticed on some other wiki site developers were maintaining a discussion by
> writing pro-con lists. I'd like to see your pro-con thoughts on making this factory.
> What would be the advantages? What would be the disadvantages?
The factory is not the key point, the key point is that I would like to
have a clean separation of GUI and test elements. Then for example I
could create a command line tool to record test plans and use the same
functionality to create test elements that is used by the GUI. And I
could run this recorder on a linux box without X-Windows because the GUI
would not be used in that case. This is not possible at the moment.
Anyway, I will stop this discussion now. I see no way to convince you
that a clean separation of GUI and model is an advantage and you will
not convice me that it is good as it is now. As nobody else seems
interested in this topic I'll stop wasting our time.
Oliver
>
> -Mike
>
>
>>Oliver
>>
>>
>>>
>>>
>>>>Oliver
>>>>
>>>>
>>>>
>>>>
>>>>>--
>>>>>Michael Stover
>>>>>mstover1@apache.org
>>>>>Yahoo IM: mstover_ya
>>>>>ICQ: 152975688
>>>>>AIM: mstover777
>>>>>
>>>>>---------------------------------------------------------------------
>>>>>To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
>>>>>For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>--
>>>Michael Stover
>>>mstover1@apache.org
>>>Yahoo IM: mstover_ya
>>>ICQ: 152975688
>>>AIM: mstover777
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>>>
>>>
>>
>>
>
>
>
> --
> Michael Stover
> mstover1@apache.org
> Yahoo IM: mstover_ya
> ICQ: 152975688
> AIM: mstover777
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
>
Re: Modified test tree
Posted by Mike Stover <ms...@apache.org>.
On 4 Feb 2003 at 0:15, Oliver Rossmueller wrote:
> No, one factory to create all of them. In fact it is just
> Class.forName(elementClassName).newInstance(). Filling the properties
> with default values should not be done by the GUI but in the element's
> constructor. So the only property the test element constructor can not
> set is the gui class name. But the test element should not know about
> GUIs anyway so I don't see the need to hold the name of the
> corresponding GUI class in the test element's properties. There are
> other ways to assign GUIs to test elements (e.g. ask the GUI which kind
> of test elements it can handle and then select the right one) and to
> keep separation of concerns. The test elements are the model and should
> not know about the very existence of a GUI.
Couple things. One, I'd like to avoid a 1:1 mapping of testelements to gui classes.
Right now, 5 guis can serve the same test element, and that's a nice feature. It
means I can make a different gui for the HTTP Sampler if I want, and the only thing
I have to write is the GUI - I don't have to make a new copy of the HTTPSampler
class.
Two, related to that is that the GUI's are the authorities on how to initiate test
element's and their data - because they fully control the data that goes into them
anyway.
Three, the gui class is saved in the test element so that when test plans are
reloaded, JMeter knows which gui goes with it. Otherwise, you need that 1:1
mapping to figure it out, plus that would be slower, as JMeter would have to search
through all the gui classes to find the right one.
As far as I'm concerned, the separation of concerns is not violated by the
testelement holding gui related data. As long as the code is completely ignorant,
I'm not worried about what data the gui's stuff in them.
I noticed on some other wiki site developers were maintaining a discussion by
writing pro-con lists. I'd like to see your pro-con thoughts on making this factory.
What would be the advantages? What would be the disadvantages?
-Mike
>
> Oliver
>
> >
> >
> >
> >>Oliver
> >>
> >>
> >>
> >>>--
> >>>Michael Stover
> >>>mstover1@apache.org
> >>>Yahoo IM: mstover_ya
> >>>ICQ: 152975688
> >>>AIM: mstover777
> >>>
> >>>---------------------------------------------------------------------
> >>>To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> >>>For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> >>>
> >>>
> >>
> >>
> >
> >
> >
> > --
> > Michael Stover
> > mstover1@apache.org
> > Yahoo IM: mstover_ya
> > ICQ: 152975688
> > AIM: mstover777
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> >
> >
>
>
--
Michael Stover
mstover1@apache.org
Yahoo IM: mstover_ya
ICQ: 152975688
AIM: mstover777
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: Modified test tree
Posted by Oliver Rossmueller <ol...@tuxerra.com>.
Mike Stover wrote:
> On 3 Feb 2003 at 23:26, Oliver Rossmueller wrote:
>
>
>>Mike Stover wrote:
>>
>>>Ok folks, 1.8.1 is out of the way (I'll be making a src release file too, later). I've
>>>just committed my changes to make the test tree hold TestElement objects instead
>>>of GUI objects.
>>>
>>>It was both easier and harder than I thought it would be originally. Please check it
>>>out and put it through it's paces. I think I touched all the important points, but we
>>>need to be sure. One thing though, it is much faster loading big test plans :-)
>>
>>Mike,
>>
>>I walked through your changes and I guess you touched all the important
>>points. Although, there is one fact that I don't like in the current
>>solution: the GUI components are test element factories. I would like to
>>separate these two concerns, the responsibility of the GUI components
>>should be to edit/modify the test elements but not to create them.
>
>
> But since the GUI objects have to know all about the TestElements anyway, why shouldn't they
> serve as factories for their creation? Otherwise, we need a new class for every TestElement
> just to create them?
No, one factory to create all of them. In fact it is just
Class.forName(elementClassName).newInstance(). Filling the properties
with default values should not be done by the GUI but in the element's
constructor. So the only property the test element constructor can not
set is the gui class name. But the test element should not know about
GUIs anyway so I don't see the need to hold the name of the
corresponding GUI class in the test element's properties. There are
other ways to assign GUIs to test elements (e.g. ask the GUI which kind
of test elements it can handle and then select the right one) and to
keep separation of concerns. The test elements are the model and should
not know about the very existence of a GUI.
Oliver
>
>
>
>>Oliver
>>
>>
>>
>>>--
>>>Michael Stover
>>>mstover1@apache.org
>>>Yahoo IM: mstover_ya
>>>ICQ: 152975688
>>>AIM: mstover777
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>>>
>>>
>>
>>
>
>
>
> --
> Michael Stover
> mstover1@apache.org
> Yahoo IM: mstover_ya
> ICQ: 152975688
> AIM: mstover777
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
>
Re: Modified test tree
Posted by Mike Stover <ms...@apache.org>.
On 3 Feb 2003 at 23:26, Oliver Rossmueller wrote:
> Mike Stover wrote:
> > Ok folks, 1.8.1 is out of the way (I'll be making a src release file too, later). I've
> > just committed my changes to make the test tree hold TestElement objects instead
> > of GUI objects.
> >
> > It was both easier and harder than I thought it would be originally. Please check it
> > out and put it through it's paces. I think I touched all the important points, but we
> > need to be sure. One thing though, it is much faster loading big test plans :-)
>
> Mike,
>
> I walked through your changes and I guess you touched all the important
> points. Although, there is one fact that I don't like in the current
> solution: the GUI components are test element factories. I would like to
> separate these two concerns, the responsibility of the GUI components
> should be to edit/modify the test elements but not to create them.
But since the GUI objects have to know all about the TestElements anyway, why shouldn't they
serve as factories for their creation? Otherwise, we need a new class for every TestElement
just to create them?
>
> Oliver
>
>
> >
> > --
> > Michael Stover
> > mstover1@apache.org
> > Yahoo IM: mstover_ya
> > ICQ: 152975688
> > AIM: mstover777
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> >
> >
>
>
--
Michael Stover
mstover1@apache.org
Yahoo IM: mstover_ya
ICQ: 152975688
AIM: mstover777
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: Modified test tree
Posted by Oliver Rossmueller <ol...@tuxerra.com>.
Mike Stover wrote:
> Ok folks, 1.8.1 is out of the way (I'll be making a src release file too, later). I've
> just committed my changes to make the test tree hold TestElement objects instead
> of GUI objects.
>
> It was both easier and harder than I thought it would be originally. Please check it
> out and put it through it's paces. I think I touched all the important points, but we
> need to be sure. One thing though, it is much faster loading big test plans :-)
Mike,
I walked through your changes and I guess you touched all the important
points. Although, there is one fact that I don't like in the current
solution: the GUI components are test element factories. I would like to
separate these two concerns, the responsibility of the GUI components
should be to edit/modify the test elements but not to create them.
Oliver
>
> --
> Michael Stover
> mstover1@apache.org
> Yahoo IM: mstover_ya
> ICQ: 152975688
> AIM: mstover777
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
>