Smart contracts testing

[greenhat]

Motivation

The smart contract developers need to test their code before deploying it to the blockchain. Often, the smart contract code cannot be fully tested in isolation, and it needs to be tested in the context of the blockchain data (other accounts, notes, etc.) and/or with the accompanying off-chain code (building transactions, analyzing notes, etc.).

Testing smart contracts in isolation (unit tests)

It's tempting to go the regular Rust unit tests route and implement the Miden stdlib, compiler intrinsics (hmerge, etc.) in Rust, emulating the Miden VM ops and stdlib functions semantics. However, this approach has the significant drawback - we will be testing the user's code against the Rust implementation of the Miden VM and stdlib, not the actual Miden VM and stdlib. The Rust implementation may have bugs, and the user's code may work in these tests but fail in the actual Miden VM.
Instead, we should offer an ergonomic way of compiling their smart contract's crate to MASM and running them in the actual Miden VM. This way, the users can be sure that their code will work in the actual Miden VM.
I'm thinking of something like the following Rust pseudocode:

let miden_package = compile("path/to/smart_contract_rust_crate");
let miden_vm = VM::load(miden_package);
let args = vec![1, 2, 3];
let result = miden_vm.call("function_name", args);
let expected_result = 6;
assert_eq!(result, expected_result);

Since the compilation and loading of the Miden package into the VM are expensive operations, we should offer a way to cache them and reuse them in the user tests.

Testing smart contracts in the context of the blockchain data on off-chain code (integration tests)

Not all smart contracts can be tested in isolation. Some smart contracts depend on the blockchain data (other accounts, notes, etc.) and/or the accompanying off-chain code (building transactions, analyzing notes, etc.).
We could offer to spin a local Miden node to the developer and use it in the tests, but it sounds quite heavyweight and might be an overkill. Instead, I suggest we look into the simulation of the blockchain itself(mockchain). I've used a similar approach in the previous L1 project, and it was very popular, especially when testing or demonstrating complex scenarios like DEX orders interaction, algorithmic stablecoin bank + oracle testing, etc.

I'm still figuring out the implementation details, but the idea can be demonstrated with the following Rust pseudocode:

// The following code does not represent any meaningful scenario, it's just a demonstration of the mockchain API capabilities

// The engine that simulates the blockchain
let mockchain = Mockchain::new();
let alice_account_package = compile("path/to/alice_account_rust_crate");
let alice = mockchain.create_account("Alice", alice_account_package);
// Mints and deposits some coins to the account
alice.deposit(Asset::new("BCoin", 100));
let note1_script = compile("path/to/note1_rust_crate");
// Execute a tx which creates a note with a given note script as a recipient
let note1 = alice.create_note(Asset::new("ACoin", 100), note1_script);
let bob_account_package = compile("path/to/bob_account_rust_crate");
let bob = mockchain.create_account("Bob", bob_account_package);
bob.deposit(BCoin, 100);
let note2_script = compile("path/to/note2_rust_crate");
let note2 = bob.create_note(Asset::new("BCoin", 100), note2_script);
let create_note_tx_script1 = compile("path/to/tx_script1_rust_crate");
// Directly create a tx with the given input notes and the tx script
let bob_tx = Transaction::load_account(bob)
    .input_note(note1, note_inputs)
    .tx_script(create_note_tx_script1.with_recipient(alice).with_asset(Asset::new("BCoin", 10)))
    .execute();
assert_eq!(alice.assets_quantity("BCoin"), 10);
// Finding the newly created output note 
let output_note = bob_tx.output_notes().get_by_...(...);
let create_note_tx_script2 = compile("path/to/tx_script2_rust_crate");
let alice_tx = Transaction::load_account(alice)
    // use the found output note as an input note in the subsequent tx
    .input_note(output_note, note_inputs)
    .tx_script(create_note_tx_script2.with_recipient(bob).with_asset(Asset::new("ACoin", 10)))
    .execute();
assert_eq!(alice.assets_quantity("ACoin"), 90);
assert_eq!(bob.assets_quantity("ACoin"), 10);

Under the hood, it would be miden-base testing framework + a simplified data store keeping accounts(state) and notes.
The future direction could be to run the code above in some playground in the browser and have a shareable link to discuss it with the team members and/or the community.

[gubloon]

Not sure if its relevant to ask here but since we are talking about testing, it will be good to add our thoughts on Smart Contract debugging. i.e, something like simbolik for solidity

[bobbinth]

let miden_package = compile("path/to/smart_contract_rust_crate");
let miden_vm = VM::load(miden_package);
let args = vec![1, 2, 3];
let result = miden_vm.call("function_name", args);
let expected_result = 6;
assert_eq!(result, expected_result);

A couple of comments on this:

1. Account code needs to be executed in a context of a given account so that it is able to access account storage, vault etc. So, we may need to instantiate a TransactionExecutor from miden-base to make it all work. But overall, I think some wrapper around TransactionExecutor which makes testing as simple as this sample code would be awesome.
2. I'm not sure how calling by function name will work once we move to the MAST-based package format. It may be that once we get miden_package we can look up MAST roots by name in it, and then use these MAST roots to execute relevant procedures.

Testing smart contracts in the context of the blockchain data on off-chain code (integration tests)

Agreed that this would be awesome. We do have a miden-mock crate in minde-base - but it needs to be heavily refactored an maybe we should do something along the lines you've listed here.

Also, cc @hackaugusto and @phklive.