Closed iphydf closed 6 years ago
@JFreegman, @nurupo, @robinlinden please review this design doc.
Reviewed 2 of 2 files at r2. Review status: all files reviewed at latest revision, 4 unresolved discussions.
toktok/designs/osmock.md, line 35 at r2 (raw file):
together with the system's responses, in an execution trace. We can then later replay this trace to reproduce bugs. We can also use stored execution traces to ensure that toxcore behaves the same for the same input.
What information would the mocker/tracer record?
As far as I understood, it would record just:
e.g.
00:00:01 malloc ( 16 ) = 0xf7f27000
00:00:05 malloc ( 16 ) = 0xf7f0a000
pretty much a strace-like output.
This is not enough information replay toxcore execution, you don't even know which toxcore functions called those mallocs, or which toxcore functions called those toxcore functions that have called the mallocs, etc.
If there is more tracing information being recorded than this then it would be less confusing if you mentioned it, unless I missed it and you can point me to it.
toktok/designs/osmock.md, line 58 at r2 (raw file):
* It should be able to record toxcore API calls, so that we can replay the activity of any API user without having to manually reproduce the API calls that led to the execution.
This point looks a bit out of place in a system call mocking proposal. So far you have talked about mocking system calls by providing an IO interface called Env
, which would provide implementations for such system calls as memory allocation, time, network stack, probably also sleep, etc., but now you seem to be talking about providing Tox API mocking/tracing, so that you would know which toxcore API functions, with which arguments and at what time a client calls. You are no longer talking about system call mocking, which is what the title of this proposal. Perhaps change the title a little and elaborate more on how the API tracing would be done?
toktok/designs/osmock.md, line 137 at r2 (raw file):
doesn't need to mock malloc and random number generators, but injects hstox-generated network messages into the receive queue of the system under test (i.e. toxcore). Using QuickCheck, we can explore properties of the entire
I don't understand how would that work. hstox would inject network messages into toxcore's simulated network queue? But all it can use to do this injection is the toxcore's system call mock, no? I don't think you have provided enough information for me to understand how is that going to work.
Comments from Reviewable
This change is