Dispatch Test Cases

Integration vs. Communication vs. Capacity Test Events

This guide outlines steps and test cases for running Integration Tests. To avoid confusion, the differences between Integration, Communication, and Capacity test events are described here.

How to Schedule an Integration Test

Webhook Push Notifications

Leveraging the webhook trigger test notification endpoints ( meter | group) in the Leap developer portal is an easy way to test your dispatch event processing logic. These test endpoints enable you to send test event notifications to your webhook endpoint as often as you’d like and with whatever payload variations you choose. You can trigger these test notifications in both the Leap staging and production environments.

Simply follow the steps below for each test case:

1. Click on the EXAMPLES dropdown menu in the top-right corner of the black 'Try It!' box

2. Choose the program event you want to start with

   • This will auto-fill the request BODY PARAMS with the example values for that program event

3. Change the request BODY PARAMS as needed for your test case

   • Note: performance_compensation_cap, priority, is_voluntary, and dispatch_event_types values are already set correctly for each program event

4. Add additional meter_dispatches and timeslots objects within the request BODY PARAMS section as needed

5. Click the 'Try It!' button to send your webhook endpoint the test event notification

integration_test_notification Field

These trigger test notification endpoints use the same service and infrastructure (e.g. source IPs) as actual market/program events. The only difference is the integration_test_notification field in the post body being set to true, indicating that it was initiated through one of these test endpoints.

Dispatch Event Polling

Testing options for dispatch event polling integrations are currently limited so spoofing the response payloads in your environment is required for testing the integration. In some limited cases, test dispatch events can be created in the staging environment and occasionally in the production environment as well. Reach out to your account manager if you'd like to discuss these options.

Core Event Processing Test Cases

Test Case 1: Initial event scheduled correctly and downstream action is taken appropriately

• Simple case of a single meter or group ID and a single event within timeslots array

Test Case 2: Multiple events received in same notification and downstream action is taken appropriately

• Single meter or group ID with multiple events within timeslots array
• Multiple meter or group IDs each with one or more events within timeslots array

Test Case 3: Modification to existing scheduled event

• Common modifications include:
  • Increased kW
  • Updated end time (shortened or extended)
  • Updated end time up to a few minutes in the past for an ongoing event (indicating that the event is now over)
  • Additional values added to dispatch_event_types array (e.g. capacity-test scheduled first and then later day-ahead is added when award is received in the market)

Test Case 4: Cancellation of existing scheduled event

• cancelled field set to true

Test Case 5: Multiple sequential events are scheduled correctly

• Two or more adjacent timeslots for the same meter/group ID (e.g. 7-8pm and 8-9pm events received within the same notification or separate notifications)

Test Case 6: Overlapping events are scheduled correctly

• Two or more events with timeslot durations that overlap for the same meter/group ID (e.g. 5-6pm and 5-9pm events received within the same notification or separate notifications)

Overlapping Events

It is possible to receive overlapping dispatches for certain timeslots if events are triggered for different reasons or for multiple programs so ensure that your implementation can process and combine these overlapping time periods appropriately. See example scenarios below.

Dispatch Strategy Scenarios

Dispatch Strategy A (responding to all events) is covered by the core event processing scenarios above. The remaining strategies are outlined below.

Test Case 7: Dispatch Strategy B - When max event duration constraints exist

• Highest priority hours are chosen by using the priority field (with highest energy_kw as tiebreaker)

Test Case 8: Dispatch Strategy C - When controlling onsite batteries

• Discharge rate is updated where appropriate and based on the performance_compensation_cap field (e.g. grid-exports-allowed or up-to-site-load)

Test Case 9: Dispatch Strategy D - When prioritizing along with outside factors and additional flexibility is needed

• The is_voluntary field is used to limit dispatch activity for non-mandatory events under the desired conditions.