Skip to content

Mock sdk/syscalls for testing #1731

Open
@Stebalien

Description

@Stebalien

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:

  1. A compile time flag to enable the mock sdk/runtime.
  2. A special MockRuntime trait that:
    1. Is invoked by the mock syscalls/sdk.
    2. Is implemented by the user and/or testing framework.
  3. 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.
  4. 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.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions