Consider a new approach to test programs

[shamilsan]

A new approach to test programs

This approach is mostly inspired by the Lunatic project.

Main concerns with gtest and gclient

gtest

• Need to reimplement many routines for the second time inside gtest crate
• Need to track gtest has a compatible version with gstd and mates
• We have a library that needed to be learned before use

gclient

• Very long compile time
• Large target directory
• Need to add unrelated dependencies
• Long time testing
• Need to run Gear node before running tests
• Need to write additional tests incompatible to gtest
• Need to reimplement many routines for the second time inside gclient crate
• We have a library that needed to be learned before use

New approach details

We don't need to build native binaries for tests but use Wasms with the external runner instead.

Step 1. Configure the program to build to wasm32-unknown-unknown target

Create config.toml in .cargo subdirectory:

[build]
target = "wasm32-unknown-unknown"

[target.wasm32-unknown-unknown]
runner = "gear run"

Step 2. Configure the program to be a dynamic library

[lib]
crate-type = ["rlib", "cdylib"]

Step 3. Implement custom #[test] attribute-like macro that exports test functions

We implement our custom #[test] attribute-like macro that is to be used instead of the default #[test] attribute.

use gtest2::test;

#[test]
fn my_test() {
    assert!(true);
}

See this macro implementation example in lunatic-test crate.

Step 4. Implement gear run subcommand that finds test functions and runs them

We need to add a subcommand in gear binary that opens Wasm binary, finds test functions inside it and runs them. cargo test will execute the runner with the test Wasm as an argument.

The good news is that the test binary also contains smart contract exports (init, handle and so on). Therefore, we can use it both as a contract binary and as a test binary. This is true for unit tests but not true (by default) for integration tests. To include contract exports to the integration tests binary we are to include the contract's rlib to the tests module:

use my_program as _;

#[test]
fn my_intgration_test() {
   assert!(true);
}

Also, there is a good implementation of such kind of runner in lunatic runtime.

Step 5. Implement a super lightweight library that use minimal number of imports

The good news is we can reuse many functions from gstd for testing purposes. For example, we can use msg::send etc. for sending messages, exec::block_height to get the current block number, prog::create_program to create a new program.

We don't need to rewrite tons of methods that are already declared.

The only thing we are to add in our new gtest2 crate is the minimal count of extrinsics that are not present in the "standard" library (gstd and mates).

Let's imagine what the test can look like.

use gstd::{exec, msg, prog};
use gtest2::test;
use my_program as _;

#[test]
fn my_new_test() {
    let code_id = gtest2::upload_self_code();
    let (_, prog_id) = prog::create_program(code_id, b"salt", "INIT", 0).expect("Failed to create program");
    let msg_id = msg::send(prog_id, "PING", 0).expect("Failed to send");
    let reply = gtest2::get_from_mailbox(msg_id).expect("No message in mailbox");
    assert_eq!(reply.dest, msg::source());
    assert_eq!(reply.payload, "PONG");
}

Pros

• Lightweight and blazingly fast test library
• Compile/test time dramatically decreases
• No excessive dependencies
• Same tests for gtest-level and gclient-level tests (can be chosen by additional argument when calling cargo test)
• No need to rewrite tons of functions in gtest/gclient
• Familiar syntax similar to the program itself
• Possibility to test programs against the real blockchain but without engaging network level
• No need for .binpath file etc. (as the test binary is the program binary as well).

Cons

• Need to install gear binary before writing tests
• Need to implement the new approach

[NikVolf]

Please avoid this vague issues that don't have straight implementation path and touch multiple components