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 Fri, 29 Jul 2016 12:15:31 GMT
On Friday, July 29, 2016, Antonio Gomes Rodrigues <ra0077@gmail.com> wrote:

> My opinion
>
> The "github diff" is a false problem, users must use comment when they
> commit

diff in git is very useful.
As a developer I highly use it, so I think it's a good point from Vladimir

>
> About users who don't like the GUI, a DSL is mandatory but not necessarily
> the target of JMeter

yes.


>
> About jsr223 XXX, if JMeter become a full DSL like
> LoadRunner/Gatling/Grinder/...., we can remove all of them and use the
> original language (Scala in Gatling, C in Loadrunner...) to add missing
> functionality

I don't think the target is to remove UI.
I personnally think it's a big power of Jmeter and highly increased
productivity of test development.
DSL only is less productive.


>
> Thanks to the ruby-jmeter  feedback
>
> @Philippe, do you want to replace GUI by a DSL or do you want to add a DSL
> to JMeter?

No , Keep improve UI but introduce dsl or compent first then dsl.

>
> Antonio
>
> 2016-07-29 13:06 GMT+02:00 Vladimir Sitnikov <sitnikov.vladimir@gmail.com
> <javascript:;>>:
>
> > >I think it ends up being a dsl anyway no ?
> >
> > It ends up being write only DSL.
> > We can put whatever makes sense for humans, and do not care
> > of the grammar/parsing stuff.
> >
> > The set of "printed" values/fields could even depend on the project.
> > For instance, some kind of regexp for "exluded/included" header names so
> > the output is both concise and useful at the same time.
> >
> > >Or does it in your mind work only from xml => comment
> >
> > As I stated in the comment itself, the comment is not supposed
> > to be modified. Neither it is supposed to be parsed by JMeter.
> > It is there for presentation purposes only, so dump views like "github
> > diff"
> > can make a basic sense of a file and show a decent diff.
> >
> > >If so it does not answer the requirement of some users to be able to
> > change
> > >the plan without xml format.
> >
> > I do understand that "pretty-printer in the comment" does not cover all
> > the use cases.
> > However, I think pretty printer will be both useful and easy to implement
> > at the same time.
> >
> > my concern about language would be:
> > > - its popularity ,
> > > - its easyness for users
> > > - it's easyness to build dsls
> > > - its future
> > >
> >
> > I would add IDE support to the list as well
> >
> >
> >
> > > Groovy is ASF now also and it's already embedded.
> > >
> >
> > This does not immediately solve "easyness for users" problem of Groovy.
> > Have you seen Groovy puzzlers?
> > https://www.infoq.com/presentations/groovy-puzzlers ,
> >
> > Take a jsr223 preprocessor that has 4 to 10 lines of groovy code in it,
> how
> > > do you represent it ?
> > > That's what I mean.
> > > It can make dsl less readable.
> > >
> >
> > Do you mean "abandon jsr223 in favor of a full blown programming
> language"?
> > Initially I thought you wonder how to add "a jsr223 preprocessor" when
> > using some kind of DSL.
> >
> > When using a programming language, some kind of IDE is required to craft
> > the script.
> >
> > I find "http sampler" rather hard to express in DSL so it is readable.
> > >
> > >
> > > look at ruby-jmeter it does a nice job at doing that
> > >
> >
> > ruby-jmeter implements just a small subset of the options that can be
> > configured in JMeter UI.
> > It will hardly be that much readable when order options are
> > implemented/used (e.g. lots of parameters passed to the application).
> >
> > Vladimir
> >
>


-- 
Cordialement.
Philippe Mouawad.

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