Charging platforms have an awkward testing problem: the production environment is thousands of physical machines, bolted to walls, owned by customers, with drivers standing in front of them. You can't "just test in prod", and you can't haul a fleet into a lab.
So the discipline becomes: simulate honestly, gate every release, load-test continuously, and — the part we think too few vendors do — publish the evidence. Here's how that works for us in practice.
Simulating a fleet that lies to you
The heart of pre-production testing is OCPP simulation: virtual charge points that connect, boot, heartbeat, charge and fail like real ones. The mistake is simulating well-behaved chargers — because real fleets aren't.
Our simulator profiles are built from production traffic patterns, which means they include the pathology: chargers that reconnect forty times an hour, out-of-order transaction events, meter values in the wrong units, stop notifications that arrive twice or five minutes late, boot storms after a simulated power cut at a fifty-charger site. Every failure mode we've catalogued in the field eventually becomes a simulator behaviour — the regression suite is, in a real sense, our accumulated scar tissue.
The same rig covers version breadth: simulated 1.6J, 2.0.1 and 2.1 devices side by side, because mixed fleets are the steady state and normalisation bugs live at the seams between versions.
Every release carries its own evidence
Each service in the platform ships through a pipeline with non-negotiable gates: the full test suite passes, coverage is measured, and the release record itself carries the results. That's not internal trivia — it's published. Every entry on our changelog shows its test count and pass status, pulled straight from the delivery pipeline, because a release note that says "various improvements" with no evidence attached is asking for trust rather than earning it.
The rule that makes this work: releases are immutable artifacts. A version that passed its gates is the exact artifact that reaches staging and production — same checksum, same rollout machinery we use for charger firmware. What was tested is what ships, or nothing ships.
Load-testing on a schedule, not after incidents
Performance testing that happens "when we're worried" measures nothing, because the baseline drifts invisibly between scares. Ours runs twice weekly, every week — Tuesday and Friday — against staging, exercising the API surfaces that matter under realistic concurrency: session queries, charge point commands, telemetry ingestion.
Each run records latency percentiles (p95/p99), throughput, error rates and availability, attached to the release under test. Two things make the cadence valuable:
- Trends beat snapshots. A p95 that crept from 60ms to 110ms across four runs is a conversation before it's an incident. The same principle we preach for charger KPIs applies to the platform itself.
- Regressions get pinned to releases. When a number moves, the diff between the two releases under test is short and recent. Debugging performance against a continuous baseline is a different sport from debugging it from a cold start during an outage.
And again: the results are public. Our performance page shows per-service latency, availability and pass/fail status from these runs — including the failures. A dashboard that only ever shows green is indistinguishable from a dashboard that isn't connected to anything.
Testing the safety nets themselves
The final layer is the one that's easy to skip: verifying the protective machinery, not just the features.
- Rollback drills. Cohort rollouts with automatic rollback only protect you if rollback actually works — so it gets exercised deliberately, with induced failures, not discovered during a bad Friday.
- Chaos on the ingestion path. Kill connections mid-transaction, replay event backlogs, drop a simulated site offline for six hours and reconnect it — then assert that sessions reconcile and nobody gets double-billed. At-least-once delivery is a promise you test, not a phrase you write.
- Restore, not just backup. A backup that's never been restored is a hope. Restore drills are scheduled, timed and logged.
Why publish any of this?
Partly philosophy: we sell evidence-over-adjectives as a procurement principle, so we should be subject to it. Partly incentive design: engineers ship differently when the test count and the p95 go on the public record with their release. The published number isn't marketing that happens to be true — it's the same number we manage by, exposed.
If you're evaluating any platform vendor — us included — ask to see this machinery: the simulator's failure profiles, the release gates, the load-test cadence, the last rollback drill. The answers are either specific or they aren't.
Every AmpNexus release ships with its test results on the changelog; load-test evidence is live on the performance page.