lq64
25ecc1e097
Added realistic user behaviour Smoke Test 1 user, runs once. Executes the full user journey exactly once. The goal is a fast sanity check — if this passes, the system is up and the critical path (register, login, import, move, resign) works end-to-end. Run this before any heavier test. --- Load Test Ramps up to maxUsers (default 10) over rampDuration (default 60s). Simulates normal growing traffic. Users are added gradually, each completing the full journey. This reveals how the system behaves under typical production load and establishes a performance baseline (response times, error rates) to compare other tests against. --- Stress Test Starts at startUsers (default 2), adds usersIncrement (default 2) users every stepDuration (default 30s) for steps (default 2) steps, with ramps between. Deliberately pushes the system beyond normal capacity in controlled steps. Each step holds load steady before increasing, so you can pinpoint exactly at which user count the system starts degrading or failing — the breaking point. --- Endurance Test Holds concurrentUsers (default 3) constant for duration (default 300s). Keeps a steady number of users playing full games repeatedly over a long period. This is the most important test for detecting slow degradation — memory leaks, connection pool exhaustion, database lock buildup — things that only appear after sustained use rather than under peak load. --- Spike Test Baseline → sudden burst of spikeUsers (default 15) → 5s pause → back to baseline. Simulates an unexpected traffic surge (e.g. a news article or viral moment). Tests whether the system can absorb a sudden large wave of users registering and starting games simultaneously, and whether it recovers cleanly once the spike subsides. --------- Co-authored-by: LQ63 <lkhermann@web.de> Reviewed-on: #7 Reviewed-by: Janis <janis-e@gmx.de> Co-authored-by: Leon Hermann <lq@blackhole.local> Co-committed-by: Leon Hermann <lq@blackhole.local>
Gatlin
Load and integration tests for the Kubernetes cluster, built with Gatling (Scala DSL).
Prerequisites
- A JVM (21+) — required to run the Gradle wrapper
- No local Gradle or Scala installation required — the wrapper downloads both automatically
Running simulations
./gradlew gatlingRun \
-PbaseUrl=http://<cluster-service> \
-PauthToken=<bearer-token>
On Windows:
gradlew.bat gatlingRun -PbaseUrl=http://<cluster-service> -PauthToken=<bearer-token>
The bearer token can also be supplied via the environment variable GATLING_AUTH_TOKEN instead of -PauthToken.
Running a specific simulation
./gradlew gatlingRun --simulation simulations.SmokeTestSimulation \
-PbaseUrl=http://<cluster-service> \
-PauthToken=<bearer-token>
Reports
HTML reports are generated under build/reports/gatling/ after each run.
Adding a new simulation
- Create a class in
src/gatling/scala/simulations/that extendsBaseSimulation. - Define your scenario and call
setUp(...).protocols(httpProtocol)— the bearer token and base URL are inherited automatically.
package simulations
import base.BaseSimulation
import io.gatling.core.Predef._
import io.gatling.http.Predef._
class MyServiceSimulation extends BaseSimulation {
private val scn = scenario("My Service")
.exec(
http("GET /api/resource")
.get("/api/resource")
.check(status.is(200))
)
setUp(
scn.inject(rampUsers(10).during(30))
).protocols(httpProtocol)
}
Project structure
src/
gatling/
scala/
base/ - BaseSimulation (shared protocol, auth)
simulations/ - one class per scenario group
resources/
gatling.conf - Gatling configuration overrides
data/ - CSV feeders
bodies/ - request body templates