Integration Tests Binary (Chain simulator)

MIPs
1

The problem:

  1. Smart Contract developers cannot test cross-shard asynchronous calls.
  2. Smart Contract developers cannot test their contracts properly when working with system VM - delegation, delegation manager, esdt.
  3. Working with elements such as randomness, scProcessor and other components in integration tests is not as practical or possible as it is on mainnet or testnet.

The current possibilities:

  1. RUST unit tests
  2. RUST integration tests
  3. WhiteBox testing with RUST
  4. Mandos testing - all until this point - this testing is a single VM with simulated async calls
  5. MX-PY
  6. MX-JS
  7. xSuite

The solution:

To resolve the above-mentioned problems we want to create an environment that can be easily integrated in multiple testing suites using multiple languages. We see that RUST developers would prefer testing in RUST, those who know more Python would write tests in Python and verify those, and others prefer testing in JS/TS.

We would like to create an environment where integration tests could be run in milliseconds, blockchain can be set up easily: custom storage, tokens, deployments (like from mandos), set balance, and set key value.

The basic idea is to create a binary that has full block and transaction processing capabilities, including cross-shard execution, node API, and is as lightweight as possible. Execution of tests should be done in milliseconds.

  1. We create a setup of 3+1 TestProcessorNodes (the 3+1 configuration can be parametrized when we start this special binary)

    a.TestProcessorNode has block and transaction processing capabilities
    b. It is much lighter than a full node, there is no P2P, no consensus, and no round time to wait for blocks.
    c. One low-end machine can easily run multiple instances of TestProcessorNode.
    d. TestProcessorNode has a block processor, transaction processor, smart contract processor, system VM, blockchain hook, accounts, API.

  2. The setup has full API capabilities like a normal gateway. Tests written on top of this are easily usable directly as system tests on testnet/devnet/mainnet as well.

  3. Full gasSchedule like the public chains.

  4. Interaction through REST API so RUST, Python, JS, and TS SDKs can interact with it.

2 Likes