Skip to content

Service Testing

You can test Exonum services with the help of the Exonum TestKit. It allows to test transaction execution and APIs in the synchronous environment (that is, without consensus algorithm and network operation involved). Tests are executed in the same system process as the service code itself, allowing to more easily debug service business logic (for example, panics).

This document describes testing of Rust services with exonum-testkit crate, for Java instructions please refer to the documentation.


In most cases you want to install exonum-testkit as a development dependency, so it would be compiled for tests only. For this, add the dependency to the dev-dependencies section of the Cargo.toml file of your project:

exonum-testkit = "0.10.0"


The newest version of the testkit crate may differ from the one specified above. To find out the newest version, you may look at the repository page on Each release of the testkit crate is compatible with the specific version of the core Exonum library; the minor version of the testkit coincides with the minor version of the Exonum library it supports.

Simple usage

Transactions testing

The primary goal of this kind of tests is to check the business logic of your service, encapsulated in the execute method of transactions.

For writing your first test create tests directory according to the cargo integration testing manual. After that, create file tests/ with the content similar to the one written below.

use my_service::{MyService, MyTransaction, MySchema};
use exonum_testkit::{txvec, TestKitBuilder};

fn test_my_tx() {
    // Create simple testkit network.
    let mut testkit = TestKitBuilder::validator()
    // Create transaction.
    let tx = MyTransaction::sign(...);
    // Commit it into blockchain.
    // Check the expected result.
    let snapshot = testkit.snapshot();
    let schema = MySchema::new(&snapshot);

Here, we assume that the service developer has implemented sign constructor for MyTransaction struct, which returns a signed transaction, Signed<RawTransaction>. This method is not implemented automatically; it could be replaced with more verbose, but universal:

use exonum::messages::Message;

let tx = Message::sign_transaction(
    MyTransaction { /* fields */ },
    MyService::ID, // service identifier
    public_key,    // ...of the signer
    &secret_key,   // ...of the signer

Make sure that you have full coverage of the business logic in the execute method of your transactions.

Testkit also allows to check different orderings of transactions, including transactions for multiple services. This could allow to more efficiently test margin cases that are quite difficult (but not impossible) to produce in the real network.

let mut testkit = TestKitBuilder::validator()
// Create transactions.
let tx1 = MyTransaction::sign(...);
let tx2 = OtherTransaction::sign(...);
// Commit them into the blockchain.
testkit.create_block_with_transactions(txvec![tx1, tx2]);
// Check the expected result.

API testing

The basic workflow for testing API endpoints of an Exonum service with the testkit is as follows:

  1. Define the MyServiceApi trait for the TestKitApi structure that covers the whole API of your service.
  2. Implement functions that use some transactions as test data to fill the storage.
  3. Create the tests that check all of your endpoints.
// API trait definition.
trait MyServiceApi {
    fn get_public_data(&self) -> PublicDataResponse;
    fn get_private_data(&self) -> PrivateDataResponse;
    fn post_private_data(&self, data: &PrivateData)
        -> PostPrivateDataResponse;

impl MyServiceApi for TestKitApi {
    fn get_public_data(&self) -> PublicDataResponse {

    fn get_private_data(&self) -> PrivateDataResponse {

    fn post_private_data(&self, query: &PrivateDataQuery)
        -> PostPrivateDataResponse

fn my_api_test() {
    let mut testkit = TestKitBuilder::validator()
    fill_storage_with_data(&mut testkit);
    // Check API responses
    let api = testkit.api();

// Other tests...

In some situations, it can be useful to see the content of requests and corresponding responses. exonum-testkit provides simple logging implementation for this purpose. You can use RUST_LOG environment variable to enable logs:

RUST_LOG=exonum_testkit=trace cargo test

Advanced Usage

The testkit allows to test more complex behaviors of Exonum services, such as getting data from external sources and reconfiguring the service.

Oracles Testing

The oracle is a service which can produce transactions with external data after commit of the block. The Bitcoin anchoring service is an example of an oracle. Just like a real Exonum node, the testkit maintains a pool of unconfirmed transactions (aka the mempool). Thus, transactions created by the oracle service during the after_commit execution will be stored in TestKit memory pool and can be verified accordingly.

// Create testkit with the service which creates transaction
// with the height of the latest committed block after commit.
let mut testkit = TestKitBuilder::validator()

// Call the `after_commit` event.

// Check that `after_commit` has been invoked
// at the correct height.
let tx = TxAfterCommit::new_with_signature(


In order to invoke a after_commit event, you need to create a block with one of the create_block* methods of the testkit.

If the oracle has to fetch any data from external world, you need to create a mock object that would generate said external data to accomplish testing.

// Provide a mock object for the service.
let mut cruel_world = ExternalApiMock::new();
let mut testkit = TestKitBuilder::validator()

// Expect a request from the service.
cruel_world.expect_api_call(ApiCallInfo { ... })
    .with_response_ok(ApiResponse { ... });

// Call the `after_commit` event.
let expected_tx = MyOracleTx::sign(...);

// Check that the expected transaction is in the memory pool.

Configuration Changes Testing

If an Exonum service has its own configuration, you may need to test the response to a configuration change. To do this with the testkit, you can create a configuration change proposal and then commit it.

let mut testkit = TestKitBuilder::validator()

// Create a configuration change proposal.
let proposal = {
    let mut cfg = testkit.configuration_change_proposal();
        MyServiceCfg { ... },
let stored = proposal.stored_configuration().clone();

// Check that there is no following configuration scheduled
// before a block is created, and the proposal is committed.
use exonum::blockchain::Schema;
// Check that the following configuration is now scheduled.