The test-as-code path is the recommended workflow for teams that version their load test scenarios alongside their application code. You write your simulation in Java, Kotlin, Scala, JavaScript, or TypeScript, package it with the corresponding Gatling build plugin, and upload the resulting artifact to Gatling Enterprise Edition. From there, the platform handles provisioning load generators, distributing the test across locations, and collecting metrics at scale.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/gatling/gatling.io-doc/llms.txt
Use this file to discover all available pages before exploring further.
Prerequisites
Before you can create a test-as-code test, you must have at least one package uploaded to Gatling Enterprise. Packages are built by the Gatling Maven, Gradle, sbt, or JavaScript/TypeScript plugin and registered in the Sources section of the UI.Creating a test-as-code test
Open the test creation modal
In the Tests view, click Create a test. If the Tests view is empty, click Get started with test-as-code tests. The creation modal opens.Select Test-as-code from the three available options, then click Create.
Set the general parameters
Configure the following fields:
| Field | Description |
|---|---|
| Name | A human-readable label shown in the tests table. Choose something meaningful to identify the simulation at a glance. |
| Package | The uploaded package that contains your simulation code. |
| Test | The specific simulation class to run from within the selected package. |
Configure load generator locations
Choose where Gatling Enterprise will start your load generators.For each location you add, configure:
You can add multiple locations with different generator counts to simulate geographically distributed user traffic.
- Managed Locations
- Private Locations
- Dedicated IPs
Managed locations are operated by Gatling. Each load generator has the following specifications:
- CPU: 4 cores
- RAM: 8 GB
- Network: up to 10 Gbit/s
- AP Pacific (Hong Kong)
- AP Pacific (Tokyo)
- AP Pacific (Mumbai)
- AP SouthEast (Sydney)
- Europe (Dublin)
- Europe (London)
- Europe (Paris)
- SA East (São Paulo)
- US East (N. Virginia)
- US West (N. California)
- US West (Oregon)
| Field | Description |
|---|---|
| Location | The geographic region where load generators will be spawned. |
| Number of load generators | How many parallel load generator instances to run in this location. |
| Weight distribution | Optional. When enabled, assign a percentage of the total load to each location. All weights must sum to 100%. |
Apply optional configurations
The following settings are optional. Expand each section in the test creation form to configure them.
Override the injection profile
Override the injection profile
Replace the injection profile defined in your simulation code without modifying or re-packaging it. The override completely replaces the code-defined profile and is saved with the test.Two injection models are available:
Closed model step types:
- Open model — you control the arrival rate (users per second). Choose this when testing a specific request throughput.
- Closed model — you control concurrent users. Choose this when your system queues excess traffic.
| Step | Description | Parameters |
|---|---|---|
| At Once Users | Inject a fixed number of users at once | Users |
| Ramp Users | Inject users evenly over a duration | Users, Duration (s) |
| Constant Users/sec | Inject at a constant rate | Rate (users/s), Duration (s) |
| Ramp Users/sec | Ramp the rate from one value to another | From, To (users/s), Duration (s) |
| Stress Peak Users | Inject using a Heaviside step function | Users, Duration (s) |
| Step | Description | Parameters |
|---|---|---|
| Constant Concurrent Users | Maintain a constant concurrent pool | Users, Duration (s) |
| Ramp Concurrent Users | Ramp between two concurrent values | From, To, Duration (s) |
Load generator parameters
Load generator parameters
Specify Java system properties (JVM) or JavaScript parameters and environment variables for this test. These are applied on top of the default parameters unless you uncheck Default properties.
Service Level Objectives (SLOs)
Service Level Objectives (SLOs)
Define one or more SLOs that gate the run’s success. Each SLO is evaluated over the run duration and reports the percentage of seconds the condition was met.
SLO compliance is colour-coded in the run summary:
| Field | Options |
|---|---|
| Metric | Error ratio, or Response time percentile (p50, p95, p99, p99.9, p99.99, p99.999, p99.9999) |
| Operator | Less than (<) or less than or equal (≤) |
| Threshold | Milliseconds (response time) or percentage (error ratio) |
- 🟢 Green: ≥ 99% of seconds met the condition
- 🟠 Orange: 90–99% of seconds met the condition
- 🔴 Red: < 90% of seconds met the condition
Time window
Time window
Exclude warm-up and cool-down periods from SLO and assertion calculations.
| Field | Description |
|---|---|
| Ramp Up | Seconds to exclude from the beginning of the run |
| Ramp Down | Seconds to exclude from the end of the run |
Stop criteria
Stop criteria
Terminate a run early when a metric exceeds a threshold for a given time window. Each criterion requires:
Example: stop the run if mean CPU usage exceeds 80% for the last 60 seconds.
| Field | Description |
|---|---|
| Metric | Mean CPU usage, Global error ratio, or Global response time (at a specific percentile) |
| Threshold | The value that triggers the stop condition |
| Timeframe | Duration (in seconds) the metric must exceed the threshold continuously |
Managing existing tests
From the Tests view, use the kebab menu (⋮) at the far right of any row to:- Edit test — open the creation modal pre-filled with the current configuration
- Duplicate test — clone the test to a new configuration you can modify independently
- Copy test ID — copy the UUID for use in API calls
- Delete test — permanently remove the test and its configuration
Deleting a test does not delete its historical run results. Run data remains accessible from the Trends view until explicitly deleted there.