Hey
agroenen,
People can probably make suggestions bit youre gonna need to provide a lot more concise detail thatll need clarifying. We'd need to understand the overall solution basics and the basic requirements of your system under test before anyone would be able to give you an approach for your testing, and even then the forum members wont be privy to some of the info that would steer an approach, but based on the detail you provide theres some questions below that anyone would need to answer.
Q1. Is the whole end to end solution you describe new or existing?
Q2. Customer uploads csv....does this mean you have no control over the format of the csv?
Q3. The csv records are loaded into a db and converted to json....can you confirm? It would be less efficient to persist the records as json rather than referential records in the db....i wouldnt expect you to store as json. Or do you mean that once they are extracted from the database, the db records are extracted into .json format which undergo some subsequent processing?
Q4. When you say the json messages are sent to an "event grid (that has to be a mock service for now)". Can you please expand what you mean by this please? What do you mean by even grid...are you talking about a data grid (datasource test step)? Or something else
Q5. What do you mean by 'f.e.' where you state ". How to check f.e."??
Q6. You mention message broker. Are you publishing to Message Queues/Topics?
Q7. If youre publishing to Message Queues/Topics, depending on the solution MQs have an associated table to support transactionality/idempotence. Are you able to query this via SQL?
Q8. Is this asynchronous or synchronous message exchange?
Once youve clarified the above, id start thinking about splitting the end to end messaging into testable pieces. I tend to test each point in a message journey where a message is either created, validated or transformed/translated as these points in the journey have verifiable output (to assert against).
Cheers
Rich
