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. 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/ > - 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". I find "http sampler" rather hard to express in DSL so it is readable. Vladimir
