The purpose of this index is to provide an overview of the testing approaches to be implemented by Ziggurat. It is intended to evolve as the framework matures, leaving room for novel cases and extensions of existing cases, as called for by any protocol idiosyncrasies that may come to light during the development process.
Some test cases have been consolidated when similar behaviour is tested with differing messages. The final implementation of these cases will be subject to factors such as node setup and teardown details, test run time (and potentially runtime) constraints, readability and maintainability.
Some of these tests can be executed against the same node instance without resetting or clearing the cache to cut down on node setup and teardown times. Other tests are intended for use where a new peer is needed to clean the slate for a deterministic output.
Considering Zebra doesn't yet have an RPC implementation, tests making use of it could be feature-gated; some tests could have an extra and gated RPC assertion, for instance. Many of these tests treat the node as a black box and as such, don't necessitate any RPC calls to verify the behaviour under test. That being said, relying only on the connection to ascertain a node's reaction to a particular message should be, in time, reinforced with an RPC-powered assertion if available.
As for test data, zcashd and zebra vectors should provide ample coverage, including maximum-sized blocks with many transactions (for each pool type: transparent, sprout, sapling, orchard).
Please refer to the code repo for usage instructions. As the specifications are developed we will include user instructions.
The conformance tests aim to verify the node adheres to the network protocol. In addition, they include some naive error cases with malicious and fuzzing cases consigned to the resistance tests. Most cases in this section will only require a socket standing in for the connected peer and a full node running in the background.
These tests verify the proper execution of a handshake between a node and a peer as well as some simple error cases.
These tests verify the node responds with the correct messages to requests and disconnects in certain trivial non-fuzz, non-malicious cases. These form the basic assumptions necessary for peering and syncing.
These tests aim to evaluate the proper behaviour of a node when receiving unsolicited messages post-handshake.
These tests evaluate the node's basic peering properties by building on ZG-CONFORMANCE-010 to verify the data included in the messages are in accordance with the peering status of the node.