## 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](https://developer.leap.energy/docs/dispatch-automation-v2#types-of-test-events).

## How to Schedule an Integration Test

### Webhook Push Notifications

Leveraging the webhook trigger test notification endpoints ( [meter](https://developer.leap.energy/reference/triggertestmeterdispatchnotification) \| [group](https://developer.leap.energy/reference/triggertestgroupdispatchnotification)) 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.