OCPP Charge Point Tester on Cucumber is a software tool that is designed to simulate a charge point in the Open Charge Point Protocol (OCPP) 1.6 specification using the Cucumber testing framework.
Cucumber is a behavior-driven development (BDD) testing framework that uses the Gherkin language to write test cases in a human-readable format. With the OCPP Charge Point Simulator on Cucumber, test cases can be written in Gherkin and automated using Cucumber's testing framework.
The simulator provides a set of predefined OCPP messages that can be sent and received by the charge point. These messages include basic operations such as boot notification, status notification.
You can find the latest version of the release in the Maven Central repository
Operations Initiated by Charge Point:
- Authorize
- Boot Notification
- Data Transfer
- Diagnostics Status Notification
- Firmware Status Notification
- Heartbeat
- Meter Values
- Start Transaction
- Status Notification
- Stop Transaction
Operations Initiated by Central System:
- Cancel Reservation
- Change Availability
- Change Configuration
- Clear Cache
- Clear Charging Profile
- Data Transfer
- Get Composite Schedule
- Get Configuration
- Get Diagnostics
- Get Local List Version
- Remote Start Transaction
- Remote Stop Transaction
- Reset
- Send Local List
- Set Charging Profile
- Trigger Message
- Unlock Connector
- Update Firmware
Install 1/2: Add this to pom.xml:
<dependency>
<groupId>com.extrawest</groupId>
<artifactId>bdd-charge-point-tester-via-ocpp-j</artifactId>
<version>0.1.2</version>
</dependency>
Install 2/2: Run via command line
mvn install
You need to set port via application.properties. For example:
server.port=3000
- You need to create a feature file. The file should be located in 'src/test/resources/features'.
- You need to write a test scenario. Mandatory sequence of the steps is REQUIRED.
- Run the scenario.
Or you can copy scenario script from the folder. Just change data and run
Given the Central System is started
Given the Central System is started on "129.39.32.0"
Given the Charge Point is connected
Given the Charge Point "ChargePointId" is connected
- operations initiated by CP
- operations initiated by CS
The next steps combination is used to test operation, regardless of what data will be received or sent:
When the Central System must receive "ClearCache.req"
Then the Central System must send confirmation response
When the Central System sends "Reset.req" request to the Charge Point
Then the Central System receives confirmation
The sending messages will be created with the default values:
When the Central System must receive "BootNotification.req" with given data
| chargePointModel | CurrentModel |
| chargePointVendor | CurrentVendor |
Then the Central System must send confirmation response with given data
| currentTime | any |
| interval | 60 |
| status | Accepted |
When the Central System sends "Reset.req" request to the Charge Point with given data
| type | Hard |
Then the Central System receives confirmation with given data
| status | any |
| currentTime | any |
For the sending message - current field value will be set to default value.
Given
the Central System is startedGiven
the Central System is started on "specified IP"Given
the Charge Point is connectedGiven
the Charge Point "specified Charge Point Id" is connectedWhen
the Central System must receive "OCPPMessageType.req"When
the Central System must receive "OCPPMessageType.req" with given dataThen
the Central System must send confirmation responseThen
the Central System must send confirmation response with given dataWhen
the Central System sends "OCPPMessageType.req" request to the Charge PointWhen
the Central System sends "OCPPMessageType.req" request to the Charge Point with given dataThen
the Central System receives confirmationThen
the Central System receives confirmation with given dataThen
the Central System must receive requested message. Used only with TriggerMessage.reqThen
the Central System must receive requested message with given data. Used only with TriggerMessage.req
All messages have the default values for every field. These values can be set in application.properties file. If field value is a complicated type(IdTagInfo for example) then you can specify it via JSON string. For example:
- BootNotification.confirmation.interval=60
- Authorize.confirmation.idTagInfo=IdTagInfo{expiryDate="2023-12-31T23:59:59.712244462+02:00[Europe/Kyiv]", parentIdTag=FH7R5JKK6SQ8, status=Accepted}
- Reset.request.requestedMessage=Soft
- TriggerMessage.request.requestedMessage=BootNotification
- Authorize message
- Boot Notification message
- Data Transfer message
- Meter Values message
- Status Notification message
- Change Availability message
- Clear Cache message
- Get Configuration message
- Reset message
- Trigger Message message