jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <philippe.moua...@gmail.com>
Subject Re: JMeter DSL discussion
Date Wed, 10 Aug 2016 20:00:28 GMT
Hi,
First thanks for having in mind to contribute a non gui recorder, by the
way what is the use case ?
My 2cents inline below.
Thanks

On Wed, Aug 10, 2016 at 8:55 PM, Epp, Jeremiah W (Contractor) <jepp@cas.org>
wrote:

> > -----Original Message-----
> > From: Vladimir Sitnikov [mailto:sitnikov.vladimir@gmail.com]
> > Sent: Wednesday, August 10, 2016 2:10 PM
> > To: dev@jmeter.apache.org
> > Subject: Re: JMeter DSL discussion
> >
> >> Hang on, why would you develop your DSL in a different language from
> what
> >> JMeter itself is actually written in?  This wold seem to  add an entire
> >> new toolchain to the build process.
> >
> > Can you clarify what you mean by " different language from what JMeter
> > itself is actually written in"?
> >
> > Do you suggest we should use java as a language to store JMeter test
> > plans?  I'm afraid that won't fly high.
>
> I thought he was suggesting implementing the language with Groovy, not
> using
> Groovy _as_ the language.  And no, I'm not suggesting Java would work
> better.  Quite the opposite, in fact.
>



>
> The entire point of a Domain Specific Langauge is to have precise control
> over what you can and cannot do (semantics) and how it looks when written
> out (syntax).  It's a form of abstraction.
>
> >>> - how to express what today we can do through JSR223 languages which
> >>> might be the most complex think to translate
> >>
> >> Is this really an issue?  This seems orthogonal to the goal of creating
> a
> >> language to describe _test plans_ themselves.  As long as this DSL has a
> >> way to express the JSR223 sampler, saving the actual code that goes in
> it
> >> should go without saying.
> >
> > Jeremiah, you are missing a point here.  Philippe means: "currently we
> > have to use JDS232 samples to workaround limitations of JMeter test plan
> > language".  For instance, there is no support for "arrays" in the
> > samplers, so one has to use JSR232 kind of scripts to work with arrays.
> >
>

It's much more than that and it's IMO the big power of JMeter.
Since I started writing JMeter plans, I have always had to write some part
of it (correlation part) in JSR223+Groovy.
Although over the years the volume of custom code tends to drop,  I doubt
it will be ever possible to express in a DSL all the possibilities.

But what Vladimir has in mind is maybe to use a language (Groovy or other
for example) and write in it a DSL for JMeter, in that case what I used to
do with JSR223 might be possible with this language.
But I am afraid it's a breaking change as he wrote it, I don't know how we
would be able to handle backward compatibility and Gui compat.
And using the GUI a lot (for example currently in a load testing mission) ,
I am happy to see that my productivity has even more increased with the new
features. I am now definitely convinced that it is very useful.



> > So, the quesion is "how to introduce control flow and data processing
> into
> > the DSL itself". Does it make things more clear?
>
> That does clarify, thank you.
>
> So the issue here is the current test plan implementation lacks important
> syntax and semantics for end users.  There are workarounds, but they are
> kludgy and nontrivial.  This is important information for designing a DSL.
>
> With that understanding, though, I'm somewhat worried that the actual
> internal representation of a test plan is in question. I suspect changing
> _that_ would be a considerable engineering effort.
>
> Before we take this line of thought any further, I think the actual desired
> semantics of this DSL need to be hammered out.  That is, what do people
> explicitly _need_ to be able to do?
>
> Regards,
> Wyatt
>
> Confidentiality Notice: This electronic message transmission, including
> any attachment(s), may contain confidential, proprietary, or privileged
> information from Chemical Abstracts Service ("CAS"), a division of the
> American Chemical Society ("ACS"). If you have received this transmission
> in error, be advised that any disclosure, copying, distribution, or use of
> the contents of this information is strictly prohibited. Please destroy all
> copies of the message and contact the sender immediately by either replying
> to this message or calling 614-447-3600.
>
>


-- 
Cordialement.
Philippe Mouawad.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message