OCPP CI/CD Integration Guide

In modern software development, Continuous Integration and Continuous Deployment (CI/CD) is the standard for delivering high-quality code. Yet, in the EV charging industry, many teams still rely on manual testing with physical chargers or basic GUI simulators.

This manual approach is slow, error-prone, and unscalable. By automating your OCPP testing pipeline, you can catch bugs before they reach production, ensuring that every commit to your Charging Station Management System (CSMS) is verified against a battery of real-world scenarios.

The Problem with Manual OCPP Testing

Relying on developers to manually run tests leads to several critical issues:

Slow Feedback Loop: Developers might wait days for QA to verify a change manually.
Human Error: It is easy to forget to test an edge case (e.g., "Offline StartTransaction").
"Works on My Machine": Tests that pass on a developer's laptop might fail in the cloud due to network differences.
Hardware Dependency: You cannot run 500 concurrent tests on a single physical charger.
Regression Risk: Fixing one bug often breaks another feature, which manual testing might miss.

CI/CD Fundamentals for OCPP

A robust pipeline runs a suite of tests automatically whenever code is pushed.

Code Push

→

Build

→

Unit Tests

→

OCPP Tests

→

Deploy

Mockpoint runs in the "OCPP Tests" stage, spinning up virtual chargers against your localized CSMS.

Why Mockpoint for CI/CD?

Most simulators are designed for humans (GUI), not robots. Mockpoint is different:

Single Binary: No complex dependencies (Java, Docker, Node) required to just run the tool itself.
Deterministic: It guarantees the exact same execution order every time, eliminating flaky tests.
Exit Codes: Returns 0 for success and 1 for failure, allowing pipelines to halt automatically.
Portable Scenarios: Test cases are simple YAML files stored in your git repo.

GitHub Actions Integration

Here is a complete example of a GitHub Actions workflow that spins up a CSMS and tests it.

name: OCPP Integration Tests

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  ocpp-tests:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4
      
      - name: Start CSMS
        run: |
          docker-compose up -d csms
          sleep 10
      
      - name: Download mockpoint
        run: |
          curl -L https://github.com/mockpoint/mockpoint/releases/latest/download/mockpoint-linux-amd64 -o mockpoint
          chmod +x mockpoint
      
      - name: Run OCPP scenarios
        run: |
          ./mockpoint run tests/scenarios/boot_notification.yaml --csms ws://localhost:9000
          ./mockpoint run tests/scenarios/charging_session.yaml --csms ws://localhost:9000
      
      - name: Upload test logs
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: ocpp-test-logs
          path: logs/
      
      - name: Stop CSMS
        if: always()
        run: docker-compose down

GitLab CI Integration

For GitLab CI, you can use a Service container for your CSMS.

stages:
  - build
  - test
  - deploy

ocpp-integration-tests:
  stage: test
  image: ubuntu:22.04
  services:
    - name: your-csms-image:latest
      alias: csms
  before_script:
    - apt-get update && apt-get install -y curl
    - curl -L .../mockpoint-linux-amd64 -o /usr/local/bin/mockpoint
    - chmod +x /usr/local/bin/mockpoint
  script:
    - mockpoint run tests/scenarios/*.yaml --csms ws://csms:9000
  artifacts:
    paths:
      - logs/

Jenkins Integration

pipeline {
    agent any
    stages {
        stage('Checkout') {
            steps { checkout scm }
        }
        stage('Start CSMS') {
            steps {
                sh 'docker-compose up -d csms'
                sh 'sleep 15'
            }
        }
        stage('Run OCPP Tests') {
            steps {
                sh '''
                    curl -L .../mockpoint-linux-amd64 -o mockpoint
                    chmod +x mockpoint
                    ./mockpoint run tests/scenarios/full_suite.yaml --csms ws://localhost:9000
                '''
            }
        }
    }
    post {
        always {
            sh 'docker-compose down'
            archiveArtifacts artifacts: 'logs/**'
        }
    }
}

Docker-Based Testing

If you prefer running everything in containers, you can use a separate Docker Compose file for testing.

version: '3.8'
services:
  csms:
    image: your-csms:latest
    ports:
      - "9000:9000"
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:9000/health"]
      interval: 5s
      retries: 10

  mockpoint:
    image: mockpoint/mockpoint:latest
    depends_on:
      csms:
        condition: service_healthy
    volumes:
      - ./tests/scenarios:/scenarios
    command: run /scenarios/*.yaml --csms ws://csms:9000

Run it with: docker-compose -f docker-compose.test.yml up --exit-code-from mockpoint

Test Reporting and Artifacts

A failing test without logs is useless. Always configure your CI pipeline to upload the logs/ directory as an artifact (as shown in the examples above). This allows you to inspect the exact WebSocket messages exchanged during a failed run.

Advanced Patterns

Parallel Execution

In GitHub Actions, you use a matrix strategy to run different scenarios in parallel, speeding up your pipeline.

strategy:
  matrix:
    scenario: [boot, authorize, transaction, firmware]

Pro Tip

Run a fast "smoke test" (basic boot & transaction) on every commit. Run the full regression suite (all edge cases) nightly. This balances developer velocity with deep coverage.

Conclusion

Integrating OCPP automated testing into your CI/CD pipeline enables you to refactor your CSMS with confidence. By catching protocol violations and logic errors early, you avoid the high cost of debugging production issues.

Ready to automate?

Add the Mockpoint binary to your pipeline.
Commit your first YAML OCPP scenario.
Enjoy green builds and sleep better at night.

For more testing strategies, check out our CSMS Testing Guide.