jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Epp, Jeremiah W (Contractor)" <>
Subject RE: JMeter DSL discussion
Date Fri, 12 Aug 2016 15:10:18 GMT
> -----Original Message-----
> From: Philippe Mouawad []
> Sent: Wednesday, August 10, 2016 4:00 PM
> To:
> Subject: Re: JMeter DSL discussion
> First thanks for having in mind to contribute a non gui recorder,

Don't thank me yet; legal's giving me hell over this. :(

> by the way what is the use case ?

What is the use case for a recorder that can be started without a GUI?
Well, recording from continuous integration is ours, and it's only because
of that that we can use JMeter at all.

There's also the ability to use a remote machine as the recording proxy,
though it doesn't work without some sort of display server because of the
ProxyControl's dependency on GuiPackage [0] -- we've been xvfb-run to give
it the illusion of a screen, but that's an ugly hack no one likes.

> Since I started writing JMeter plans, I have always had to write some part
> of it (correlation part) in JSR223+Groovy.

Interesting!  I'd actually be curious what that looks like.  We've been
toying with the idea of writing a delta-based auto-correlation tool to
reduce the special case tools in new products, but that takes time.

You know how it is.

> 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.

Maybe it won't be able to get _everything_-- needs change over time, after
all.  But I think it could get close to 99.9%.  And there's nothing keeping
us from adding features if they happen to be needed later.

> 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.

Thinking about this a bit more, I can see how there may be some merit to a
TestPlan API that lets you write test plans entirely in code.  But that's a
separate idea, really. For what it's worth, I strongly recommend _against_
using a full programming language as your DSL.  That's sort of the opposite
of "domain specific". *g*

> 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.

IMO, one aspect of this work should be some refactoring to decouple "JMeter,
the graphical test IDE" from "JMeter, the load execution engine".

This isn't to say the GUI is bad or should be abandoned; far from it!  It's
very important!

Tooling matters!

...But I've hit a number of snags when trying to write my proxy that where
the underlying model depends unneccessarily on GUI components.

There are abstraction leaks.



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.

View raw message