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
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.
themelio-node
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.
Correctness
-
Mainnet self-test: run
themelio-nodewith the--self-testflag. 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::RpcServicethatthemelio-nodeexposes with random garbage JSON data, attempting to crash this. This should use a tool likecargo 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
Performance
-
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?