cscore is a minimal-footprint library providing commonly used helpers & patterns for your C# projects. It can be used in both pure C# and Unity projects.
The idea is to capture all dispatched actions to the store as typed JSON with a wrapper that also contains the timestamp when they were dispatched and then build a replayer that can load these JSONs and dispatch the same actions again. This allows to record the entire interaction of the user with the application so that it can be replayed arbitrarily often for testing purposes and to investigate bugs.
The recorder middleware should have some filter functions to let the developer black or whitelist certain actions they do not want to be recorded. And it should be able to turn the recorder on and off during runtime.
The replay system should allow setting the replay speed, if the actions should happen in real time or as fast as possible or something in between. If the user did not do any action for a longer time there should also be a max time between actions the developer can specify to automatically skip these pauses during replay.
The developer should be able to tell the replay system “now load the user session from this target DirectoryEntry and start playing it”. Replaying multiple recordings after another might be tricky, for that a middleware might be needed to restore the initial state of the store before the second recording is started. And to be able to generically restore the initial state of the store the middleware has to store it in its middleware when the very first action is dispatched.
The developer should be able to build himself some UI on top of the replay system where he can load and unload arbitrary many replays during runtime, so that he can also include that system in a test version of their application.
The current implementation
The current implementation of this idea can be found in the “ReplayRecorder” class, take a look at the unit tests like TestReplayRecorder that make use of it.
This implementation does not meet all the requirements yet that are described above and should be extended and changed. Some examples where the logic should be changed:
The current “ResetStoreAction” should be deprecated in favor of the middleware storing the initial state of the store itself. Otherwise the developer using this system would have to implement in his reducers the ResetStoreAction manually. Maybe there is also some middle ground where the developer is still informed via the ResetStoreAction that this reset is happening but does not have to implement any reducer logic himself for it to happen. Then he could optionally react to the reset and maybe reset some other state of the system that is not in the store.
The ResetStoreAction.Entry class does not store the timestamp yet, so this has to be added in that class.
Collected requirements
The idea is to capture all dispatched actions to the store as typed JSON with a wrapper that also contains the timestamp when they were dispatched and then build a replayer that can load these JSONs and dispatch the same actions again. This allows to record the entire interaction of the user with the application so that it can be replayed arbitrarily often for testing purposes and to investigate bugs.
The recorder middleware should have some filter functions to let the developer black or whitelist certain actions they do not want to be recorded. And it should be able to turn the recorder on and off during runtime.
The replay system should allow setting the replay speed, if the actions should happen in real time or as fast as possible or something in between. If the user did not do any action for a longer time there should also be a max time between actions the developer can specify to automatically skip these pauses during replay.
The developer should be able to tell the replay system “now load the user session from this target DirectoryEntry and start playing it”. Replaying multiple recordings after another might be tricky, for that a middleware might be needed to restore the initial state of the store before the second recording is started. And to be able to generically restore the initial state of the store the middleware has to store it in its middleware when the very first action is dispatched.
The developer should be able to build himself some UI on top of the replay system where he can load and unload arbitrary many replays during runtime, so that he can also include that system in a test version of their application.
The current implementation
The current implementation of this idea can be found in the “ReplayRecorder” class, take a look at the unit tests like TestReplayRecorder that make use of it.
This implementation does not meet all the requirements yet that are described above and should be extended and changed. Some examples where the logic should be changed: