Releases: abstracta/jmeter-java-dsl
0.17
0.16
Now it's possible to emulate user's delays with timers using the DSL.
Check the new section in use cases document for additional details.
0.15
In this release test plan statistics methods minElapsedTime
, maxElapsedTime
, meanElapsedTime
, elapsedTimePercentile90
, elapsedTimePercentile95
, elapsedTimePercentile99
have been renamed to minSampleTime
, maxSampleTime
, meanSampleTime
, sampleTimePercentile90
, sampleTimePercentile95
, sampleTimePercentile99
to avoid confusion with existing elapsedTime
method.
The first set of methods is focused on time spent exclusively on sampling, while the last method is focused on time between the test plan/transaction/sample start and end. This is a significant difference, since the first ones do not take into consideration pre & post processors or timers spent time, nor parallelism execution of samplers in thread groups, while the last one does.
This is a NON BACKWARDS COMPATIBLE CHANGE, and requires any existing users to change from previous methods to the new ones to be able to use this and future versions.
We have decided to apply the changes without any deprecation notice since we are in a 0 major version and API is considered currently unstable, also avoiding in the mean time the burden of having to manage @deprecated
methods.
0.14.1
0.14
Now is possible to group requests into transactions!
Check the new section in use cases document for additional details.
0.13
Now is possible to tune fields in jtlWriter
, overwrite existing JTL file, and generate one file per response with responseFileSaver
.
Check the new section in use cases document for additional details.
0.12
Now is possible to specify a ramp-up period when creating threads in thread group!
Warning: This method is deprecated since 0.18.
Using ramp-up period avoids thread creation interfering with test collected metrics, creating them in a progressive manner.
Here is an example:
import static org.assertj.core.api.Assertions.assertThat;
import static us.abstracta.jmeter.javadsl.JmeterDsl.*;
import java.io.IOException;
import java.time.Duration;
import org.junit.jupiter.api.Test;
import us.abstracta.jmeter.javadsl.core.TestPlanStats;
public class PerformanceTest {
@Test
public void testPerformance() throws IOException {
TestPlanStats stats = testPlan(
threadGroup(2, 10)
.rampUpPeriod(Duration.ofSeconds(5))
.children(
httpSampler("http://my.service")
),
).run();
assertThat(stats.overall().elapsedTimePercentile99()).isLessThan(Duration.ofSeconds(5));
}
}
0.11
Now is possible to use response assertions! E.g:
import static org.assertj.core.api.Assertions.assertThat;
import static us.abstracta.jmeter.javadsl.JmeterDsl.*;
import java.io.IOException;
import java.time.Duration;
import org.eclipse.jetty.http.MimeTypes.Type;
import org.junit.jupiter.api.Test;
public class PerformanceTest {
@Test
public void testPerformance() throws IOException {
TestPlanStats stats = testPlan(
threadGroup(2, 10,
httpSampler("http://my.service")
.children(
responseAssertion().containsSubstrings("OK")
)
)
).run();
assertThat(stats.overall().elapsedTimePercentile99()).isLessThan(Duration.ofSeconds(5));
}
}
Check Use cases documentation for mor details.
0.10
Thanks to the contribution of @MrThreepwood is now easier to use dynamically generated urls, bodies & header values in http requests. Here is an example:
import static org.assertj.core.api.Assertions.assertThat;
import static us.abstracta.jmeter.javadsl.JmeterDsl.*;
import java.io.IOException;
import java.time.Duration;
import org.apache.jmeter.threads.JMeterVariables;
import org.eclipse.jetty.http.MimeTypes.Type;
import org.junit.jupiter.api.Test;
public class PerformanceTest {
@Test
public void testPerformance() throws IOException {
TestPlanStats stats = testPlan(
threadGroup(2, 10,
httpSampler("http://my.service")
.post(s -> buildRequestBody(s.vars), Type.TEXT_PLAIN)
)
).run();
assertThat(stats.overall().elapsedTimePercentile99()).isLessThan(Duration.ofSeconds(5));
}
public static String buildRequestBody(JMeterVariables vars) {
String countVarName = "REQUEST_COUNT";
Integer countVar = (Integer) vars.getObject(countVarName);
int count = countVar != null ? countVar + 1 : 1;
vars.putObject(countVarName, count);
return "MyBody" + count;
}
}
Warning: This alternative, as in the case of JSR223 pre & post processors using Java code, only works when using embedded JMeter engine. There is no support for using it with exported JMX files in JMeter GUI, or BlazeMeter. If you need such support prefer using a JSR223 pre processor with script specified as string (Groovy script).
Additionally, this version includes some minor non backwards compatible changes:
- Change regex extractor target field enum names to be more explicit and avoid confusion.
- Rename
Jsr223PostProcessorScript
,Jsr223PostProcessorScriptVars
,Jsr223PreProcessorScript
,Jsr223PreProcessorScriptVars
to shorter forms to avoid verbosity on users code.
Finally, useDebugRun()
method has been added to BlazeMeterEngine
to allow running small tests in BlazeMeter without consuming credits, to verify that test plans properly work in BlazeMeter.
0.9
Is now possible to use Java Code without any need to specify a groovy script in JSR223 Pre & Post processors, taking full advantage of Java type safety and code auto-completion.
Here is an example:
import static org.assertj.core.api.Assertions.assertThat;
import static us.abstracta.jmeter.javadsl.JmeterDsl.*;
import java.io.IOException;
import java.time.Duration;
import org.junit.jupiter.api.Test;
import us.abstracta.jmeter.javadsl.core.TestPlanStats;
public class PerformanceTest {
@Test
public void testPerformance() throws IOException {
TestPlanStats stats = testPlan(
threadGroup(2, 10,
httpSampler("http://my.service")
.children(
jsr223PostProcessor(s -> {
if ("429".equals(s.prev.getResponseCode())) {
s.prev.setSuccessful(true);
}
})
)
)
).run();
assertThat(stats.overall().elapsedTimePercentile99()).isLessThan(Duration.ofSeconds(5));
}
}
WARNING: using this, instead of Groovy script (String), is currently only supported when using embedded JMeter engine. No support for saving to JMX and running it in JMeter GUI, or running it with BlazeMeter.
Thanks to @MrThreepwood for pushing for this support.