Skip to main content

Integration Tests

Integration tests enable you to deploy a contract in the NEAR testnet or a local sandbox and create test users to interact with it. This way, you can thoroughly test your contract in a realistic environment.

Moreover, when using the local sandbox you gain complete control of the network:

  1. Create test Accounts and manipulate their State and Balance.
  2. Simulate errors on callbacks.
  3. Control the time-flow and fast-forward into the future (Rust ready, TS coming soon).

In NEAR, integration tests are implemented using a framework called Workspaces. Workspaces comes in two flavors: 🦀 Rust and 🌐 Typescript.

All of our examples come with integration testing.

Sandbox Testing

NEAR Workspaces allows you to write tests once, and run them either on testnet or a local Sandbox. By default, Workspaces will start a sandbox and run your tests locally. Lets dive into the features of our framework and see how they can help you.

Create Accounts​

Dev Account​

Subaccount​

Using Secret Key​

Using Credentials From File​

WASM Files​

Compile Contract Code​

tip

You don't need to assert compiling process everytime. You can use ? operator to get the result as Vec<u8> without dealing with Result<Vec<u8>>, Error> type. That way you can directly use this vector to deploy the wasm file into account. Your test will still fail if compiling process fails.

let contract_wasm = near_workspaces::compile_project("./").await?;

Loading From File​

tip

The same as in the case of compilation wasm from code, you don't need to assert reading file process everytime. You can use expect method to get the reading file result as Vec<u8> and provide error message as a parameter. Your test will still fail if compiling process fails.

let contract_wasm = std::fs::read(artifact_path)
    .expect(format!("Could not read WASM file from {}", artifact_path).as_str());

Deploy Contracts​

Dev Deploy​

Deploy To Account​

Logs​

Show contract's logs.

You can use println or dbg! when you want to see information from your code.

In Rust, the output from your code is captured by default and not displayed in the terminal. In order to see the output, you have to use the --nocapture flag

eg. cargo test -- --nocapture

If you want to access the contracts logs, you can find them in the tx_outcome.logs() Vec.

let tx_outcome = user_account
        .call(contract.id(), "set_greeting")
        .args_json(json!({"greeting": "Hello World!"}))
        .transact()
        .await?;
    assert!(tx_outcome.is_success());

    dbg!(tx_outcome.logs());
    // [tests/test_basics.rs:29:5] tx_outcome.logs() = [
    //     "Saving greeting: Hello World!",
    // ]

Account Balance​

Transactions​

Call​

View​

Patch State on the Fly​

In Sandbox-mode, you can add or modify any contract state, contract code, account or access key with patchState.

You can alter contract code, accounts, and access keys using normal transactions via the DeployContract, CreateAccount, and AddKey actions. But this limits you to altering your own account or sub-account. patchState allows you to perform these operations on any account.

note

As an alternative to patchState, you can stop the node, dump state at genesis, edit the genesis, and restart the node. This approach is more complex to do and also cannot be performed without restarting the node.

Time Traveling​

workspaces offers support for forwarding the state of the blockchain to the future. This means contracts which require time sensitive data do not need to sit and wait the same amount of time for blocks on the sandbox to be produced. We can simply just call worker.fast_forward to get us further in time:

See the full example on Github.

Using Testnet​

NEAR Workspaces is set up so that you can write tests once and run them against a local Sandbox node (the default behavior) or against NEAR TestNet. Some reasons this might be helpful:

  • Gives higher confidence that your contracts work as expected
  • You can test against deployed testnet contracts
  • If something seems off in Sandbox mode, you can compare it to testnet
tip

If you can create a new account on each iteration as well.

Spooning Contracts​

Spooning a blockchain is copying the data from one network into a different network. NEAR Workspaces makes it easy to copy data from Mainnet or Testnet contracts into your local Sandbox environment:

Specify the contract name from testnet you want to be pulling, and a specific block ID referencing back to a specific time. (Just in case the contract you're referencing has been changed or updated)

Create a function called pull_contract which will pull the contract's .wasm file from the chain and deploy it onto your local sandbox. You'll have to re-initialize it with all the data to run tests. This is because the contract's data is too big for the RPC service to pull down. (limits are set to 50Mb)

Snippets​

Snippet I: Testing Hello NEAR​

Lets take a look at the test of our Quickstart Project 👋 Hello NEAR, where we deploy the contract on an account and test it correctly retrieves and sets the greeting.

Snippet II: Testing Donations​

In most cases we will want to test complex methods involving multiple users and money transfers. A perfect example for this is our Donation Example, which enables users to donate money to a beneficiary. Lets see its integration tests

Additional Resources​

Advanced Examples​

Test Driven Design Using Workspaces and AVA​

The video below walks through how to apply TDD with Workspaces and AVA for a simple contract: