Re: Question on testing properties in JMeter

[Vladimir Sitnikov <si...@gmail.com>]

>When I run ./gradlew test -Djmeter.use_java_regex=true, it seems to have
>more effect

I have no idea how it works now, however, there are three JVMs:
1) The first JVM evaluates the build script (it basically runs
build.gradle.kts, and it is the JVM that parses the build command-line)
2) The second JVM runs @Test classes
3) Then a test class might fork another JVM with JMeter

>Or would I have to add a
>passProperty("jmeter.use_java_regex"|"jmeter.regex_engine" ) call?

passProperty is needed to pass properties (sorry for duplication) between
#1 and #2 above.
If @Test class forks a JVM for JMeter, then it should somehow pass
properties on its own.

Of course, we can follow the "defer to System.properties by default"
approach, and we could ensure
all JVM forks pass jmeter.regex_engine (e.g. all jmeter.* properties) to
the forked JVMs via their system.properties.
I am afraid it would create tight coupling on System.properties, thus it
would make it harder to
launch JMeter instances in "isolation" within a single JVM.

On the other hand, if we prefer that System.properties contain no
JMeter-specific properties,
then we might end up with a better design, where all the properties could
be passed explicitly (via the constructor or whatever),
and it would make it easier to test: test parallelism is easier to manage
when tests do not require mutating the global state like System.properties.

So I am inclined we should favor designs where all the properties are
passed explicitly (e.g. via mask),
instead of "all properties occurring in System.properties automagically".

WDYT?

Vladimir

Re: Question on testing properties in JMeter

[Felix Schumacher <fe...@internetallee.de>]

Am 01.03.22 um 12:03 schrieb Vladimir Sitnikov:
>> When I run ./gradlew test -Djmeter.use_java_regex=true, it seems to have
>> more effect
> I have no idea how it works now, however, there are three JVMs:
> 1) The first JVM evaluates the build script (it basically runs
> build.gradle.kts, and it is the JVM that parses the build command-line)
> 2) The second JVM runs @Test classes
> 3) Then a test class might fork another JVM with JMeter
>
>> Or would I have to add a
>> passProperty("jmeter.use_java_regex"|"jmeter.regex_engine" ) call?
> passProperty is needed to pass properties (sorry for duplication) between
> #1 and #2 above.
> If @Test class forks a JVM for JMeter, then it should somehow pass
> properties on its own.
>
> Of course, we can follow the "defer to System.properties by default"
> approach, and we could ensure
> all JVM forks pass jmeter.regex_engine (e.g. all jmeter.* properties) to
> the forked JVMs via their system.properties.
> I am afraid it would create tight coupling on System.properties, thus it
> would make it harder to
> launch JMeter instances in "isolation" within a single JVM.
>
> On the other hand, if we prefer that System.properties contain no
> JMeter-specific properties,
> then we might end up with a better design, where all the properties could
> be passed explicitly (via the constructor or whatever),
> and it would make it easier to test: test parallelism is easier to manage
> when tests do not require mutating the global state like System.properties.
>
> So I am inclined we should favor designs where all the properties are
> passed explicitly (e.g. via mask),
> instead of "all properties occurring in System.properties automagically".

I have implemented a passing of system properties that match those with 
"jmeter.properties." as prefix in PR 700.

With that I can provide a system property named "jmeter.use_java_regex" 
to the unit tests run by gradle with

./gradlew test -Djmeter.properties.jmeter.use_java_regex=true

I believe, that is what you tried to explain to me.

Felix

>
> WDYT?
>
> Vladimir
>