Description

This PR adds two test cases for EventHistory's getEvents method, validating that:

• testGetEvents_MultipleRequests_EnforceOrder_UsesPreviousOldest: When using ordered search, it properly uses the oldest occurrence date of the first result as the starting time range for the next event
• testGetEvents_MultipleRequests_NoOrder_ReturnsResultsInSameOrder: When more than one event is passed, results are returned in the same order
  • It also validates that bugs like returning the same result for all requests arent happening

This PR adds two test cases for EventHistory’s getEvents method, validating:

testGetEvents_MultipleRequests_EnforceOrder_UsesPreviousOldest

• When enforceOrder is enabled, the from timestamp for each following request is correctly using the oldestOccurrence of the previous result.

testGetEvents_MultipleRequests_NoOrder_ReturnsResultsInSameOrder

• Verifies that when multiple requests are made with enforceOrder disabled, the results are returned in the same order as the requests.
• Also validates that bugs such as returning the same result for all requests do not occur (which I don't think is caught by any case currently?).

To support testing this multi-event getEvents case, MockEventHistoryDatabase has been updated to allow:

1. Setting multiple return values via returnSelectResultsQueue, which acts as a FIFO queue.
2. Each of the param properties has been updated to use an array backing, allowing capture of multiple sets of parameters from method calls.

• Backward compatibility is maintained by converting the existing param properties into computed .last accessors of the backing arrays.
  • My understanding is that since the purpose of these properties is to record parameters from method calls, and not to be set directly in tests, removing the ability to set them manually isn't a breaking change.

Related Issue

Motivation and Context

How Has This Been Tested?

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• I have signed the Adobe Open Source CLA.
• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.