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.
