OCPI Testing Tools and Strategies: A Practical Guide

OCPI is a financial protocol. Bugs in your implementation cost real money — miscounted CDRs, lost sessions, billing disputes, partner relationships strained. Good testing is not optional. (If you are new to the protocol, start with what OCPI is before diving into testing strategy.)

But OCPI doesn’t have the rich testing ecosystem some protocols have. There’s no Postman collection that exercises every spec corner. There’s no community-maintained certification suite. You build your own test infrastructure or you ship bugs.

This article covers the testing approaches that actually work in production OCPI deployments, the tools that exist, and the gaps you’ll need to fill yourself.

The testing pyramid for OCPI

A reasonable structure:

1. Unit tests: for your business logic, your data transformations, your parsers. Fast, exhaustive, run on every commit.
2. Schema validation: for every outgoing payload, ensure it conforms to the OCPI JSON Schema. Run in CI.
3. Mock-partner integration tests: a mock partner you control, exchanging full request-response cycles for each module. Run in CI.
4. Real-partner integration tests: against a sandbox or test environment of a real partner. Run weekly or before each release.
5. Production smoke tests: after deploying, exercise the live endpoints against a known partner. Run automatically post-deploy.
6. Observability: real-time monitoring of production traffic to catch issues in flight.

Each layer catches different bugs. Skip any layer and you’re betting that the bugs that layer would catch don’t exist in your code.

Schema validation: the cheapest big win

The single most valuable testing investment for OCPI is JSON Schema validation in CI.

Community-maintained OCPI JSON Schemas exist for 2.1.1 and 2.2 (less complete for 2.2.1 and 2.3 in 2026). Find them via the OCPI working group’s repository or community efforts on GitHub.

What to do:

• Add a CI step that runs every outgoing payload through the schema validator.
• For every module you implement (Locations, Sessions, CDRs, etc.), have a representative test that constructs the payload and validates it.
• Treat schema failures as build failures.

What this catches:

• Missing required fields.
• Wrong types (string where number expected, etc.).
• Wrong format (date strings that aren’t ISO 8601 UTC, country codes that aren’t ISO 3166 alpha-2).
• Wrong enum values.
• Out-of-range numerics.

Most “the partner’s parser failed” bugs would be caught here. Implementing schema validation typically takes a few days; it pays back within weeks in fewer support tickets.

Mock partners: building your own

A mock partner is a server you build that speaks OCPI well enough to round-trip every message your real code uses. Many of the integration pitfalls ^{(coming soon)} teams hit in production are cheap to reproduce and pin down inside a mock first.

A useful mock supports:

• The Credentials handshake (token A → token B → token C exchange).
• Versions endpoint negotiation.
• All modules you support, on both client and server sides.
• Realistic data (Locations with proper structure, Sessions with valid state transitions, CDRs with consistent meter readings).
• Optional misbehavior modes (return 500, return malformed JSON, delay response by 30 seconds) for testing your error handling.

Building a basic mock is one engineer-week or so. Maintaining it as you add modules is ongoing but small.

Some open-source mocks exist (search GitHub for “ocpi mock” or “ocpi simulator”) with varying coverage. Most teams end up writing their own because their mock needs to match their specific use cases.

Run the mock as part of your CI suite. Tests should include:

• Round-trip every module: PUT a Location to the mock; the mock then GETs Locations from you to verify. Repeat for each module.
• Full session lifecycle: Authorize → Session start → multiple Session updates → Session end → CDR delivery.
• Error path: send a malformed payload; verify your error response is well-formed.
• Pagination: ask for paginated data; verify you handle the Link header correctly.

Real-partner sandbox testing

Mocks catch your bugs. Real partners catch the spec-vs-implementation differences that exist between every OCPI implementation in production.

Most major hubs and large operators offer sandbox or test environments. Use them:

• Before going live with the partner, exchange data in a sandbox.
• Periodically (monthly or quarterly), run regression tests against the sandbox.
• Before a major release, smoke-test in sandbox.

What you’ll find that the mock didn’t:

• Subtle differences in how the partner formats their data (extra fields, missing optional fields, formatting variations).
• The partner’s specific tariff structures (different from your test fixtures).
• The partner’s specific Locations structure (different from your idealized test Locations).
• Realistic latencies (partners are slower than your in-memory mock).
• Realistic error rates (real networks have hiccups).

Test data realism

A common testing failure: your test data is too clean. Real production data has weird stuff that your tests should also have:

• Locations with mixed-case names, special characters, multi-language strings.
• Tariffs with edge-case structures (very high prices for some markets, very low for others, complex restrictions).
• Tokens with unusual character sets.
• Session timestamps that span timezone-change boundaries (DST transitions).
• CDRs with negative energy values (V2G or measurement errors).
• Empty optional fields.
• Maximum-length strings.

Generate realistic test data. Borrow from real partner samples (with permission and anonymized). Test the unhappy data shapes, not just the happy ones.

The Credentials handshake — special attention

Credentials is small but bug-prone. Allocate disproportionate test attention to it. The token exchange also carries your authentication and security ^{(coming soon)} posture, so getting these paths right protects more than just registration.

Test cases to include:

• Happy path: token A exchange, register, both sides accept.
• Token A already used: should reject.
• Token A expired: should reject.
• Token B unreachable when partner tries to register: handle timeout gracefully.
• Multiple registrations from same partner: handle as token rotation or as duplicate.
• Token rotation in flight when partner reboots: recover cleanly.
• Mismatched country_code or party_id: reject with clear error.
• Partner sends a Credentials object with a role you don’t recognize: handle gracefully (accept the role, log it, continue).
• Multi-role Credentials: a partner declaring CPO + Hub roles in one Credentials object.

If your Credentials handshake works in all these cases, you have a robust handshake. If it fails any, you have a production support ticket waiting to happen.

Idempotency testing

OCPI partners retry. Your code must handle retries correctly.

Test for each module:

• POST the same Session update twice. Verify state is correct (not duplicated).
• POST the same CDR twice. Verify only one CDR is stored.
• POST a Location PUT twice with identical content. Verify no spurious update event.
• POST a Location PUT twice with slightly different content. Verify the update is applied (idempotent on identical content, applied on different content).

These bugs are common. Tests catch them early.

Concurrency testing

In production, you’ll receive many requests in parallel. Your code must handle concurrent updates without corruption.

Test:

• Concurrent Session updates for the same session. Verify final state is consistent.
• Concurrent Location PUTs for the same location. Verify last-write wins or your defined semantics.
• Concurrent Authorize requests with the same idTag. Verify your eMSP query doesn’t fan out to N duplicate queries.

Most CI environments don’t easily stress-test concurrency. Use targeted tools (k6, Locust, custom scripts) and run separately from your unit test suite.

Tools and libraries

A short list of useful OCPI testing tools and resources.

OCPI JSON Schemas — community-maintained. Search GitHub. Use them in your CI for schema validation.

ocpp-js / ocpi-js / similar SDKs — language-specific helpers that handle some of the boilerplate. Quality varies; review before depending on.

Charging-station simulators with OCPP and OCPI bridges — open-source projects like EVerest, SteVe (OCPP-focused), and others that include some OCPI capability.

Mock partner templates — search GitHub for “ocpi mock,” “ocpi sandbox,” “ocpi simulator.” Several community projects exist; pick one or fork to your needs.

Postman collections — some community-built Postman collections for OCPI exist for manual testing. Useful for exploratory work.

The OCPI spec itself — the example payloads in the specification documents are valuable test fixtures. Use them.

CI integration

How to integrate OCPI testing into your CI pipeline:

1. Unit tests run on every commit. Fast, exhaustive, business logic.
2. Schema validation runs on every commit. Verifies that data structures conform to the spec.
3. Mock-partner integration tests run on every commit. Full round-trip for each module.
4. Real-partner sandbox tests run nightly. Catches regressions caused by spec interpretation drift.
5. Production smoke tests run after every deploy. Verifies the deploy is working before declaring success.

Total CI runtime should be a few minutes for the per-commit tests, plus the longer nightly runs. If your tests take 30 minutes to run, engineers will skip them; keep them fast.

Observability is testing too

Your production code is the longest-running, most comprehensive test of your OCPI implementation. Observability turns production into a test signal:

• Per-partner error rates. A spike in a specific partner’s error rate is a bug indicator.
• Per-module latency. A slow Module is a hint at a database or logic issue.
• Per-message-type counts. Drops in expected message types indicate broken pipes.
• CDR-to-session ratio. Every session should produce a CDR; a divergence is a bug.

Build dashboards for these. Alert on anomalies. Use production data to find the bugs your tests missed.

What good test coverage looks like

A reasonable target for OCPI test coverage:

• Unit test coverage: 70-90% of business logic.
• Module integration tests: 100% of modules you support, both client and server sides.
• Edge case tests: at least 5-10 per module covering unhappy paths.
• Credentials handshake: 10+ test cases covering happy path and edge cases.
• Performance tests: load test against a realistic mock at 2-3x your expected production traffic.
• Schema validation: 100% of outgoing payloads validated in CI.

If you can hit these targets, you have a strong OCPI testing posture. Most teams don’t; investing here is high-ROI.

The honest summary

OCPI testing is your insurance against expensive production bugs. The spec gives you the contract; testing verifies that you and your partners agree on the contract’s interpretation. Build a mock partner. Validate every payload against the schema. Test the unhappy paths. Use real partner sandboxes. Treat observability as a continuous testing layer. With those habits, OCPI integration is reliable. Without them, every new partner is a new source of fire-fighting.