On Friday, July 29, 2016, Vladimir Sitnikov <[email protected]> wrote:
> 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: > https://gradle.org/blog/kotlin-meets-gradle/ 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 > -- Cordialement. Philippe Mouawad.
