Disclaimer: I wish there were some real-life use-cases for creating test scripts in a programmatic way. Note: toy examples like <<visit name: 'Google Search', url: ' http://google.com'>> do not count. I would like to hear from real-life requirements for DSL.
99.999% of the scripts I've faced are build with two simple techniques: 1) Copy paste from similar scripts 2) Record via proxy controller I have only one use case in mind for "simplified text DSL": UC1) Simplified text DSL script that is used to drive web browser in terms of "click this link, click that link", while JMeter is creating its regular jmx behind the scenes (http proxy) at the same time. The rationale is: 1) When application code changes, it is typically easier to re-record from scratch rather than debugging JMeter scripts / regexps 2) User-facing part is typically more stable (link labels are more stable than regexps, sets of parameters passed, etc) 3) "High level" step names might be used when recording. That is JMeter could sniff transaction names right from the tool that drives the browser. 4) The produced JMeter script can be used for a load test (that is the test with high number of virtual users) since it does not require browser. Note: that use case does not require for JMeter to be DSL-first. It does not require JMeter to read DSL and represent that as UI elements. It does not require JMeter to write DSL out. Philippe Mouawad: > > > "Reading" is a rabbit hole. > > For instance, if a user writes some random code (with for loops, > > try-catches, etc), how JMeter should read that into a UI and write that > > back? That scares me. > > > why not map each element to a keyword of dsl. > Foreach would be used for ForEach Controller . > No try/catch concept > 1) Inventing some nice looking output is relatively easy. Making that "nice looking text" parseable is extremely hard. That is what all language holywars are about. Don't you suggest inventing yet another general-purpose programming language? 2) When working off some existing language (e.g. Groovy, Kotlin, Ruby or whatever), there always be a problem that "certain language elements are forbidden since they cannot be expressed in JMeter UI. Are you going to forbid all the standard library, ban all the control flow elements, etc, etc? Otherwise users would write something like (from ruby-jmeter home page): threads count: 100, scheduler: true, start_time: Time.now.to_i * 1000, end_time: (Time.now.to_i * 1000) + (3600 * 1000) Note how Time is native to ruby class. Even if it were in JVM-based language, it would be hard to read the above and represent in the JMeter UI properly (and being able to serialize to exactly the same code!) Guess what happens if user (developer) declares a helper method or class, so It is not I'm sure it will be hard to load that into JMeter while keeping that script sensible, debuggable, etc. It is not even a try-catch. It is not even OOP-based script (see https://github.com/flood-io/ruby-jmeter/blob/master/examples/real_user_objects_github.rb#L94 ). Being able to read and make sense of more complex scripts (like "page object" one: https://github.com/flood-io/ruby-jmeter/blob/master/examples/real_page_objects.rb ) is close to impossible with current JMeter UI and set of controllers. Vladimir
