Hi, One question, "View Results Tree" is very useful (check the answer, validate our regex,...). How do you want to implement it with a DSL?
I have talked with the creator of Gatling and one of his goal with Gatling is to have a diff between 2 scripts. It's one reason he have made a DSL Other people I have seen whose use Gatling for good reason (not performance reason (JMeter could do the job with their load)) is because they don't like GUI and would code. About Grinder, I don't think it's a good comparaison (in France) because there are few experts and documentation (one of my customer have abandoned Grinder to Gatling) If you take Loadrunner, it's a is "DSL-based" (the script is written in C) and it's more popular than Neoload (which is a GUI tool) In my opinion there a 2 targets: allow to easily make a diff between 2 scripts have a DSL to people wanting code instead of GUI Another question, why don't ask to merge ruby DSL to JMeter core or push rucy DSL to check if people use it? Same question about some JMeter plugin which I think will be in JMeter core F.Y.I. The creator of Gatling have created his enterprise to develope/sell Gatling They (they are 5 full time developpers) have created a commercial release of Gatling called Gatling Frontline. The use of Gatling are growing (a lot of user in USA ans more and more in France (the creator have made a lot of meetup)) Another thing is that Gatling is much younger than JMeter and change habit take time. My other answer inside the mail 2016-07-29 0:36 GMT+02:00 Vladimir Sitnikov <[email protected]>: > 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. > Have ypou an example because I don't see how add special comment will solve the problem > > 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 > Antonio
