I am agree with Vladimir, All the people I have seen who use Loadrunner (including me) re-record from scratch rather than debugging scripts. And after they (still including me) check the difference between the old and the new script. Then they choose if it's easy to upgrade the old or the new
About helper/tool method in the script made with the DSL, in you work with Loadrunner expert, you will see that they have a lot of helper/tool method (e.g. read a text file and get only some line...). I have seen the same thing with Grinder I think it will be difficult to read a script with DSL + "native langage helper/tool method" and transform it in jmx file How jmeter-ruby make it? Another thing, I have never seen a load test tool which have a great DSL + a great GUI Loadrunner have a editor (like an IDE) to modify your scripts. Only some parameter have a special GUI (load a csv file, equivalent of Thread Group...) Gatling have an GUI only for record the script Gatling Frontline have a GUI to record the script and execute the script Maybe Octoperf (https://octoperf.com/) but the last time I have check it, it was not complete Antonio 2016-07-29 16:36 GMT+02:00 Philippe Mouawad <[email protected]>: > On Friday, July 29, 2016, Vladimir Sitnikov <[email protected]> > wrote: > > > 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. > > > I tend to think as you. > > So users who do that are welcome to write here. > > > > > > 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 > > > Recording could generate dsl. > > > > 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 > > > if developer knows what changed, it might be faster for him to update the > scripts. > That is one case where tester is also developer of the tested application. > > 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. > > > Having a dsl may make it easier to compare the current script and new > generated script (dsl) and then only update the changed part. > > Bit it could work with your comment oriented proposal > > > > > > > > > > > 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? > > > no just a dsl like groovy has. > > > > > > > 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? > > > no > > > > > 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!) > > > good point. > > > > > > 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 > > > > > -- > Cordialement. > Philippe Mouawad. >
