Integration testing ideas

Right now, the Themelio codebase largely uses cargo test unit testing, but we don’t have a good system of integration testing that tests the code running in a “real” scenario. Here are some preliminary ideas of tests we can run on different parts of the codebase; feel free to comment with more:


melnet2 sets up a peer-to-peer gossip-style network on which RPC verbs can be run. The main things to test are:

  • Connectivity: given enough time, most messages reach all the nodes connected to the network. The network should never form isolated partitions.
  • Performance: throughput of messages gossipped per second; time it takes for messages to reach most nodes

The mn2-gossip tool can be used as the basis of integration tests.


This can be divided into correctness and performance testing. Generally, we use a private, single-node “simnet” to do testing, except for a few tests that require a mainnet node, and others that test network behavior.


  • Mainnet self-test: run themelio-node with the --self-test flag. This continually replays, from the beginning, all blocks that have already been synced, making sure that they can be reproduced.
  • RPC fuzzing: we fuzz the nanorpc::RpcService that themelio-node exposes with random garbage JSON data, attempting to crash this. This should use a tool like cargo hfuzz.
    • Requires new RPC
  • Consensus testing: over a multinode simnet, we continually run the consensus algorithm. It should always produce the same results on the different nodes, as well as never get stuck.
    • Requires new consensus


  • Gossip latency: given a global, multinode simnet, how long do all nodes see a particular transaction in the mempool? How consistent are the mempools?
    • Requires new RPC
  • Consensus performance: given huge numbers (hundreds - thousands) of consensus nodes in a simnet, scattered across many continents, can
    • Requires new consensus
  • Transaction throughput vs consensus size: what’s the max TPS given a certain number of consensus nodes?