Extras/format converters

[pmirek]

Description

This is browser/JavaScript based set of converters to .jmx format.
Supported ones are: har, postaman collections, soapui projects.
Added to already available extras directory.

Motivation and Context

This speeds up scenario creation, when application is not available for recording requests with jmeter. It also makes possible to get as input formats available form developers (har recorded with browser) or functional testers (postman or soapui). Speeds up, as you have templates, instead of starting from the scratch.

How Has This Been Tested?

Examples are provided for testing, it was tested with them and other ones not included here.

Screenshots (if appropriate):

Provided within extras/converters directory together with md and html README.

Types of changes

• New feature (non-breaking change which adds functionality)

Checklist:

• My code follows the code style of this project. / not sure, it's JavaScript mainly, not Java.
• I have updated the documentation accordingly.

[vlsi]

Thanks for the contribution.
Could you please clarify why you have chosen browser-based converter rather than integrating the converter to JMeter itself?

If the converter is in Java/Kotlin, then it could use regular APIs to build the tree, and we won't need to support tree generation in several places.

WDYT?

[pmirek]

If you have JavaScript/browser based solution, you can promptly test it and see the results immediately. JavaScript probably can be easier for contribution to add more converters, as it's claimed to be most coded language, if I can believe in stats: https://www.statista.com/statistics/793628/worldwide-developer-survey-most-used-languages/

That was also was my case - I know Java and JavaScript, Kotlin not yet. Though testing with JavaScript was much faster in contrast to recompiling and testing with Java. Also I didn't need to know whole context of integration. Conversion is "easy" task and don't need benefits of Java to make work done.

Although I can get the point. I've also though about integration with core JMeter (and Java usage for this), but that was more time consuming (which I didn't have at this point). It always can be a starter, so another people can take a look into and convert to core JMeter with Java or Kotlin if they have time for this and better experience. This is up to your decision guys.

[vlsi]

Let us see what the others would say, however, have you thought of writing tests for your converters?
I'm not comfortable maintaining code that has no tests.

[ra0077]

Hi Vladimir and pmirek
About HAR file import, I am working on it (with https://github.com/sdstoehr/har-reader library and check how curl import has bee developped)
It doesn't seem very complicated to do, but it's going to take me a little time because I haven't coded in a long time.

[pmirek]

Testing of the code sounds reasonable. What would be expected/preferred way?

[vlsi]

We do not have much JavaScript code yet, and we do not have build and testing for JS. So it would be great if you could recommend something (jest?).

By the way, have you considered TypeScript?
I think having stronger types would make it easier to maintain as the compiler would verify property names.

PS. We have a HTML+JS-based report in https://github.com/apache/jmeter/tree/master/bin/report-template Currently it does not use bundler, howewer, it might be a good idea to combine them (js report, js converter)

[pmirek]

Let me check on possibilities, I probably won't go for re-typing to .ts due to lack of time, but I'll add something for testing of .js (command line based)
Combining html/js parts may be also a good idea, as more people checks bin directory than extras.

[vlsi]

I'm not sure we need to co-locate everything under the same directory when storing the files in Git though.
My suggestion was to use the same bundler/dependencies/testing for both tasks.

[pmirek]

I was looking around for some ways to test it, but so far the best I can think of is to use nodejs for command line based testing producing output and doing basic validation, but this is different environment that the one currently used for compiling and packaging JMeter. If you are OK with this way I can make a try. If you have came across anything else, please let me know.
BTW, I've recently seen this article https://www.blazemeter.com/blog/gatling-vs-jmeter from BlazeMeter, where they are using HAR input as one of the comparison features. So it looks like providing any way, even not perfect may be useful for test developers.