ECMAScripting [Was: Re: Project directions]

[Jordi Salvat i Alabart <js...@atg.com>]

Boutcher, James K. wrote:
> I'm guessing this might be drastic, but I feel like my hands are tied
> while using the GUI to put together a test plan. Maybe it's the
> developer in me, but has anyone considered the ability to put together a
> test plan that's described in, say, ECMAScript, with scriptable objects
> we create? Then, the GUI is only a helper to generate the ECMAScript. At
> a later point, you could tweak everything with a "view source" of sorts.

Drastic indeed. A true revolution. This would make a completely
different project. Actually, it would make something very close to
PushToTest TestMaker -- which, AFAIK, is now an almost-dead project
(just as JMeter seemed to be a few weeks ago). I don't mean that it's a
dead-end: Mercury LoadRunner also works this way and it's a commercial
success. I mean that you would be better off reviving TestMaker and
starting your idea from there.

On the other side, I would absolutely be for adding some scriptable
components "to satisfy the developer in you". For example:
- A scriptable assertion which can test for more complex conditions
- A scriptable logic controller which can take more complex decisions on
which sample to use next -- or even dynamically generate a sample, and
possibly also perform before-start/after-end actions.
...

I also would like to see limited scripting functionality
replacing/complementing the current ${functions} with ECMAScript
expresions. This would also address Mike's wish to have more complex
parsing..

Being more specific, I was thinking about a simplification of the
functions functionality. A function currently produces a value from the
current test execution context, which includes the results of the last
request and little more. This causes difficulties, for example, if you
want to use a piece of info in a response two requests later. The
solution was this "variable-names" stuck to the end of the function call
so that you can (re-)use that value later on -- but it's all tied with
strings.

My idea is to create a new kind of component, an "Extractor", which
would receive samples and extract data from them, placing the results in
variables. Similar to Assertions, these extractors would most often be
placed inside a Sampler, but it could make sense to put one in a
controller if it needs to repeat the extraction for each sampler in there.

Once you have this, you can almost eliminate the concept of ${functions}
and almost stick to ${variables} -- although being able to use
expressions on the variables, possibly including real functions, would
be great. I say "real functions" because the current ones are very badly
named, since their results depend (almost exclusively) on things other
than their parameters, so they are not functions in a proper sense.

A side advantage of this "Extractor" idea is that complex stuff like
regular expressions could go into their own field in a GUI form, instead
of being embedded in a longer text.

Possible extractors:
- Regexp extractor
- Cookie extractor
- Session id extractor
- Form field extractor
and, yes,
- Scriptable extractor

Sounds good?

Salut,

Jordi.




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: ECMAScripting [Was: Re: Project directions]

[Michal Kostrzewa <M....@pentacomp.com.pl>]

+1 for Jordi's Extractors. But I'd rather see java or beanshell as the 
scripting language.

best regards
Michal Kostrzewa


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: ECMAScripting [Was: Re: Project directions]

[Mike Stover <ms...@apache.org>]

I like very much Jordi's idea of Extractors.  It meshes very well with my desire that 
JMeter address a non-developer user - it is a better and easier solution than the 
functions, and I believe it would be very easy to make.  Already Assertions are 
"run" at the end of each sample.  All that's needed is to create an Extractor 
interface and have them run at the same time.  Good idea!

PushToTest (pushtotest.com) is exactly as Jordi says, and the maker wanted to 
donate the code to Apache a while back.  I have no idea how that ended up, but 
you can talk to the owner of it, if you like, and help him bring it on as an Apache 
project, or even a JMeter sub-project.  When I talked with Frank about it, I thought 
JMeter could easily become a two-headed project, one side emphasizes scripting 
(the PushToTest software), the other side emphasizes the GUI (JMeter).  Over 
time, both begin sharing more and more code.  But it's a long road that would need 
a champion, I think.

--
Michael Stover
mstover1@apache.org
Yahoo IM: mstover_ya
ICQ: 152975688
AIM: mstover777

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>