As a QA, this is how I used the Event Store in end-to-end tests
In a truly end-to-end test automation strategy that includes validations at multiple layers through various components of a system where a QA Engineer might want to explore beyond the conventional UI and API test strategies, it is important to dig deeper into the system in order to access and test some specific aspects of an event sourcing system like the Event Store. This aspect becomes significant in data-oriented projects; especially when I, as a QA, care about testing the flow and integrity of the test data from an end-to-end perspective, i.e. starting right from the data input source all the way till the APIs and eventually the UI.
For instance, consider a part of a project that deals with the flow of data in below manner.
Here, it is important to note that the Event Store is responsible to process the sourced events, extract and process the data contained in the events and feed the same to an event post-processing component, which would eventually populate another database (say, MongoDB) with the processed data, which would eventually be massaged at the API layer and shown on the UI.
So the question is, how do I ensure that the data has been processed by the Event Store successfully and passed to the event post-processor?
Well, I did it through two steps, i.e. ensure there are no:
- In-flight events
- Parked events
I used the Event Store’s subscriptions/ API endpoint for this purpose, like illustrated in the Node.js mocha test specs below.
In-flight events
In this case, I hit the subscriptions/ endpoint and check for the attribute totalInFlightMessages in the API response and ensure it is equal to 0; if not, we retry for a maximum of 5 times before we mark the test spec as “failed”.
Parked events
Once we have checked there are no in-flight events, we can now safely check for the parked events using the same subscriptions/ API.
In this case, we hit the subscriptions/ endpoint, store the resultant JSON array in a Javascript array, hit each of the parkedMessageUri links from the array and ensure that the response code in each case is 404 since the same corresponds to the fact that there are no parked events in each of the “subscriptions”.
Conclusion
One can use the test specs like the ones mentioned above in an end-to-end CI test pipeline in order to ensure there are no in-flight and parked events as pre-requisites before performing any validations in the later components in the project.
