jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <>
Subject Re: JMeter DSL discussion
Date Fri, 29 Jul 2016 09:01:41 GMT
On Friday, July 29, 2016, Vladimir Sitnikov <>

> Philippe>- It is more readable in source repositories.
> What if JMeter had "textual representation" of a test plan saved as a
> comment in the same JMX (or a side file)?
> That makes plan "human readable", yet it does not require inventing DSLs.
> That textual representation can exclude "not important" attributes (like
> all the checkboxes HttpSampler has).
> "Readable script" & "readable git diff" can be solved by adding special
> comment.

I think it ends up being a dsl anyway no ?
To be useful , It would require jmeter to be able to read/write it so I
think work is equivalent no?

If not can you give more detail ?
Or does it in your mind work only from xml => comment

If so it does not answer the requirement of some users to be able to change
the plan without xml format.

> Philippe>- it is better for developers who load test their application in
> CI/CD.
> This is clearly an important move JMeter must follow.
> In my company we had used Grinder test tool for a while, yet we reverted to
> JMeter. Just for the reference: Grinder is "DSL-based" (the script is
> written in python).
> It turned not that easy to support python code (lack of type system, lack
> of IDE support). For complex scenarios you tend to rewrite the script from
> scratch rather than "augmenting the source code".

> For large scenarios grinder script became unreadable: the tool can hardly
> refactor the script into nice looking procedures. It just dumps all the
> http headers and parameters you have, thus the test script includes
> noticeable amount of boilerplate for each call.
> The above might got solved by some extremely clever DSL, however, I would
> not say that "just implementing DSL" would solve those automatically.
> Current power of JMeter UI is that it can easily hide not that relevant
> options from the screen, so user is focused on the important stuff.
> > If possible, we could start thinking in this thread about:
> > - its syntax, knowing we have an example which I find rather nice, easy
> > and powerful with ruby-jmeter
> >
> This basically opens a question if "JMeter DSL" should be turing-complete
> or not. Should it contain loops or not, etc.
> > - the language it should be developed in. My personal preference would go
> > for Groovy but I am not an expert in DSLs.
> >
> -1 for Groovy.
> I find it hard to debug (e.g. exceptions are cryptic), and IDE support is
> not likely to appear soon.
> Gradle build system is likely to migrate from Groovy to Kotlin:

my concern about language would be:
- its popularity ,
- its easyness for users
- it's easyness to build dsls
- its future

Groovy is ASF now also and it's already embedded.

> > - how to express what today we can do through JSR223 languages which
> might
> > be the most complex think to translate
> >
> What's complex with JSR223? That's just a "obscure text field".

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.

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

> Vladimir

Philippe Mouawad.

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