Test Cases

It is recommended to test each of the Core Event Processing scenarios below as well as the Dispatch Strategy scenarios relevant for your event processing logic. Each test case could have multiple iterations within it due to different fields in the event notification changing with each iteration. For additional details on these fields, check out the Dispatch Event Processing and Dispatches Strategies sections of the Dispatch Automation guide.

📘

Dispatch Examples per Program

An example dispatch event notification for most programs can be found within the EXAMPLES dropdown menu in the webhook Trigger Test Notification endpoints. See step #1 in the How to Test section below.

How to 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)

🚧

Make sure to keep everything else in the event notification the same including the meter_event_id or market_group_event_id

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)
  • Example CAISO scenario:
    1. DRAM/CCA capacity-test and day-ahead market award
       • E.g. 5-6pm & 6-7pm PT for 1 test meter/group (A)
       • Priority 1 (over-performance paid up-to-nomination)
    2. ELRP emergency event
       • E.g. 4-8pm PT for 2 test meters/groups (A & B)
       • Priority 3 (voluntary, over-performance paid for grid-exports-allowed)
    3. DRAM/CCA hour-ahead market award
       • E.g. 7-8pm for 1 test meter/group (A)
       • Priority 2 (over-performance paid up-to-site-load)
    4. ELRP event ends early (at some point in the middle of the event)
       • E.g. updated notification sent out with an end time a few minutes in the past (immediately ending the ongoing ELRP event)
  • Example NYISO scenario:
    1. CSRP emergency event
       • E.g 4-8pm ET for 2 test meters/groups (A & B)
       • Priority 3 (over-performance paid up-to-nomination)
    2. DLRP emergency event
       • E.g. 2-6pm ET for 1 test meter/groups (A)
       • DLRP 5 (over-performance paid up-to-nomination)

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)
  • See example in Dispatch Event & Program Prioritization guide

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