Gatling Performance Testing: Turn real workload models into executable load-test scripts

10 min read PolyForm Noncommercial 1.0.0

AI TestingAgent SkillsPerformance Test Gatling

A Gatling scenario looking like well-formed code does not mean it expresses business behavior clearly. Request chains, session data, and injection models must jointly describe a real user journey.

The Gatling Performance Testing Skill uses readable scenarios, feeders, and injection profiles to keep Scala-based load tests traceable to a business question.

This guide uses concrete scenarios to show how to collect, connect, and interpret evidence so the conclusion can support the next engineering or business decision.

Awesome QA Skills organizes Skills by language and testing stage. The series overview covers repository structure and shared installation options; this guide stays with Performance Test Gatling.

Read the source Skill first

The main prompt covers Input parsing order, Scenario selection decision tree, Defaults (use these unless the user specifies otherwise), Gotchas, Pre-delivery Checklist. Those headings are navigation; the project artifacts still provide the facts.

The source directory contains 2 example files, 3 references, 4 script entries. Start with CI integration example, Framework guide, Local smoke-test script.

From artifacts to a runnable entry point

The task is concrete: Model checkout load with Gatling, set latency and error thresholds, and correlate service metrics

The input can stay short, but it needs facts.

Journey: sign in → create order → pay → read result
Environment: staging
Available artifacts: interface definition, test account, CI command
Deliverable: src/test/scala/simulations/CheckoutSimulation.scala, plus the local command and failure evidence

The Skill should confirm versions, authentication, and data cleanup before generating files. This output fragment demonstrates structure; it does not claim a run occurred.

tool: Gatling
entry: src/test/scala/simulations/CheckoutSimulation.scala
checks: p95 latency, error rate, throughput, resource curves
run_evidence: pending

Keep run_evidence pending until a command, report, or trace exists. The source prompt also calls out Input parsing order, Scenario selection decision tree, Defaults (use these unless the user specifies otherwise).

Turn the fragment into a project skeleton

A code fragment becomes useful when its path, command, and artifacts are explicit. Start with one journey.

src/test/scala/simulations/CheckoutSimulation.scala
├── scenario and assertions
├── data or feeder
├── environment configuration
└── failure artifacts written to artifacts/

Use one reproducible local and CI command.

./mvnw gatling:test -Dgatling.simulationClass=simulations.CheckoutSimulation

Model feeder uniqueness and injection profiles before tuning assertions.

Definition of integrated

CheckMinimum barIf it fails
RepeatabilityA run does not depend on leftover dataRework setup and cleanup
DiagnosisGatling HTML report and backend resource metrics identifies the same runAdd a run ID and build ID
CI decisionProcess exit status matches the quality gateFix reporter or threshold configuration
MaintenanceShared authentication and setup have one edit pointExtract a fixture, specification, or user action

Expand into errors, boundaries, and concurrency only after this journey behaves the same locally and in CI.

A prompt you can adapt

Replace the bracketed fields with project facts. Specific material leaves less room for guessing.

Use the performance-test-gatling Skill.

Task: Model checkout load with Gatling, set latency and error thresholds, and correlate service metrics
Version and environment: [requirement / build / environment]
Inputs: [file paths or links]
Scope: [included and excluded journeys]
Constraints: [accounts, data, time, compliance]

Check framework version, paths, and authentication first. Generate the smallest runnable entry, command, and artifact list. Mark unexecuted code as not verified.
Finish with open questions. Do not invent missing facts.

Use the first pass to inspect structure and gaps. Supply missing material before asking for the handoff-ready artifact.

Advanced use, from one call to a maintained flow

Maintain injection profiles, feeders, and assertions separately. Increase capacity in stages and inspect error samples and resource inflection points at each stage.

Keep a baseline for duration, pass rate, flaky cases, failure classes, and evidence completeness. Pass rate alone hides too much.

A three-Skill chain

requirements-analysis → performance-test-gatling → test-reporting

HandoffPayloadReceiver check
Upstream to performance-test-gatlingSource versions, scope, risks, open questionsPerformance Test Gatling staleness and conflicts
performance-test-gatling to downstreamPrimary artifact, evidence index, unfinished workPerformance Test Gatling executability and owners
Feedback to performance-test-gatlingRuns, defects, new risksPerformance Test Gatling baseline and regression update

Do not paste three complete outputs into one large prompt. Give Performance Test Gatling a structured summary and accessible source artifacts. It saves context and makes defects traceable.

Team gates

GateCheckFailure action
performance-test-gatling inputVersion, environment, owner, accessible sourcesStop Performance Test Gatling and list gaps
performance-test-gatling artifactMaterial claims carry basis and statusReturn Performance Test Gatling for evidence
performance-test-gatling executionCommand, exit status, report are reproducibleClassify infrastructure or test failure
performance-test-gatling decisionResidual risks have accepter and dateDo not enter the next stage

Review Performance Test Gatling adoption, human edit rate, unsupported claims, and failure-to-diagnosis time each sprint. Record a baseline for several cycles before setting targets.

Common failure modes for this tool family

  1. Code is generated without a run command, leaving the next person unable to verify it.
  2. Versions and dependencies are omitted even though Gatling configuration and reporters change.
  3. Tests share dirty data. API, UI, and performance suites all suffer from leftovers.
  4. One green run is described as long-term stability. Keep reports, logs, and retry evidence.

Install and invoke

Install the individual Skill. The series overview carries the longer installation explanation.

npx skills add https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-types/performance-test-gatling -g

Invoke it with “Use the performance-test-gatling Skill,” then attach the real artifacts.

Two practical questions

Will Performance Test Gatling hand me a runnable project?

With complete definitions, versions, paths, and dependencies, it can generate a strong starting point. You still need to install dependencies, run it in your repository, and fix environment differences.

When should generation stop?

Stop when authentication, test data, or the target version is unknown. More generation would only produce a polished guess.

What should be checked first after generation?

Confirm that the entry command discovers the target file and writes failure artifacts to the agreed path. Expand coverage after that works.

Can it enter a release gate immediately?

Wait until local and CI runs use the same command, data resets cleanly, and evidence is traceable.

Run Performance Test Gatling against one real artifact and keep the input, output, and review notes. The fragments here establish structure; project evidence must still come from the project.

References

ACP (Agent Client Protocol)Active MemoryAgent EvalsAgentic WorkflowAI Agent
Share