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: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
