The approach I’d take here would be to look at why you need to store data for later. Presumably just storing data in the saga but never doing anything with it isn’t the end goal; instead, it’s needed because it will affect the saga’s responses to subsequent events. So the tests should look at the responses to those subsequent events. How the saga stores the data for later should be an implementation detail of no interest to other entities in the system.
In terms of Axon’s given/when/expect test structure, you’d pass the “save for later” events in the “given” part of the call to the test fixture, pass the “do something with the saved data” event to the “when”, and then in the “expect”, check that the commands or events published by the saga make use of the relevant bits of saved data.
With that setup, you can refactor the saga code (say, to only save specific fields rather than entire event objects) and be confident the change has no effect on the saga’s behavior.