Open
Description
We should have a "mock sdk" for native unit testing (i.e., without a wasm VM). For completeness, we should provide both an SDK mock and a low-level syscall mock.
The core design is to introduce:
- A compile time flag to enable the mock sdk/runtime.
- A special
MockRuntime
trait that:- Is invoked by the mock syscalls/sdk.
- Is implemented by the user and/or testing framework.
- A thread-local variable to store a
MockRuntime
. A unit test would bind a new runtime to said thread-local variable while executing the test. - Mock implementations of the syscalls and/or sdk methods that call the
MockRuntime
currently stashed in the thread-local variable instead of making "real" system calls.
Mock SDK
The first option is to mock the SDK itself. I.e., the high-level methods but not fvm_sdk::sys::*
.
Advantages:
- Higher-level and easier to mock.
Disadvantages:
- Can't be used to test the SDK.
- Not appropriate for testing alternative SDKs.
Mock Syscalls
The second option is to mock fvm_sdk::sys
. Basically, we'd replace the current FFI declarations with actual functions that call into a mock runtime.
Advantages:
- Low-level and suitable for testing the SDK itself.
Disadvantages:
- Requires re-implementing the FVM's logic around IPLD block IDs.
- Annoying to work with low-level/FFI-safe types (lots of encoding, decoding, raw pointers, etc.