Epp, Jeremiah W (Contractor)> > To preface, we're doing something rather unusual in that we're actually > generating test plans in CI from our functional tests using a command-line > recorder daemon I wrote (based on JMeter; I'm still trying to get > permission > to release the source) and then correlating them with post-processing > scripts. >
That is cool. > > > - the language it should be developed in. My personal preference would go > > for Groovy but I am not an expert in DSLs. > > Epp, Jeremiah W (Contractor)> > Hang on, why would you develop your DSL in a different language from what > JMeter itself is actually written in? This wold seem to add an entire new > toolchain to the build process. > Can you clarify what you mean by " different language from what JMeter itself is actually written in"? Do you suggest we should use java as a language to store JMeter test plans? I'm afraid that won't fly high. Philippe> - how to express what today we can do through JSR223 languages which might Philippe>be the most complex think to translate Jeremiah>Is this really an issue? This seems orthogonal to the goal of creating a Jeremiah>language to describe _test plans_ themselves. As long as this DSL has a way Jeremiah>to express the JSR223 sampler, saving the actual code that goes in it should Jeremiah>go without saying. Jeremiah, you are missing a point here. Philippe means: "currently we have to use JDS232 samples to workaround limitations of JMeter test plan language". For instance, there is no support for "arrays" in the samplers, so one has to use JSR232 kind of scripts to work with arrays. So, the quesion is "how to introduce control flow and data processing into the DSL itself". Does it make things more clear? Vladimir
