tests.rs

Overview

This file contains integration and asynchronous tests designed to verify the behavior of blockchain-related components, specifically focusing on monitoring and reacting to changes in blockchain peer data. It uses a local database and asynchronous concurrency primitives to simulate and observe blockchain state changes in a controlled test environment.

Detailed Explanation

Imports and Dependencies

• std::collections::HashMap: Used to manage a collection of peer data keyed by peer identifiers.

• itertools::Itertools: Provides additional iterator methods, such as join, used to format collections for output.

• tvm_types::AccountId: Represents the unique identifier for a blockchain account or node.

• crate::resolver::blockchain::{watch_blockchain, NodeDb}: Imports the blockchain monitoring function and the database abstraction used to read blockchain state.

fn node_db() -> NodeDb

Creates and returns a new instance of NodeDb initialized with a hardcoded path to a local database file.

Parameters: None
Returns: NodeDb — a database handle to the blockchain archive.

Usage:
This function encapsulates the creation of the database instance, providing a consistent database reference for tests or other functions within this file.

#[tokio::test] async fn test_proxy_list()

An asynchronous test function that verifies the ability to watch blockchain events and receive updates about peers.

Purpose:

• To spawn a background task that listens for blockchain updates using watch_blockchain.

• To subscribe to changes in peer information.

• To print the current list of proxies (peers) after a short delay to allow initial data loading.

Parameters: None
Returns: () (unit) — test functions return nothing but signal pass/fail to the test harness.

Step-by-step behavior:

1. AccountId Creation:
   Creates a default AccountId filled with zeros ([0u8; 32]), representing self_peer_id.

2. Channel Setup:

   • subscribe_tx, subscribe_rx: A Tokio watch channel transmitting a vector of vectors of peer identifiers (initially empty).

   • peers_tx: A watch channel for a HashMap keyed by peer identifiers, initially empty. The receiver side is unused here.

3. Spawning Blockchain Watcher:
   A Tokio task is spawned that calls watch_blockchain with:

   • Two copies of the same NodeDb instance.

   • The self_peer_id.

   • The transmitters for subscription and peers.

4. Sleep Delay:
   The test sleeps asynchronously for 1 second to allow the watcher task to initialize and populate subscription data.

5. Subscription Data Processing:

   • Clones the current subscribed data from subscribe_rx.

   • Transforms each inner vector of peer identifiers into a comma-separated string using join.

   • Collects these strings into a vector.

6. Output:
   Prints the vector of formatted peer strings.

Usage Example:

#[tokio::test]
async fn my_test() {
    test_proxy_list().await;
}

This test can be run with cargo test -- --nocapture to see the printed output.

Implementation Details and Algorithms

• The test leverages Tokio's asynchronous runtime and watch channels for communication between tasks.

• watch_blockchain presumably polls or subscribes to blockchain events, updating the channels with new peer lists and blockchain state.

• The test ensures that asynchronous state changes can be observed and that the subscription mechanism works as expected.

• The use of tokio::time::sleep introduces a fixed delay to allow asynchronous initialization, which is common in integration tests interacting with asynchronous streams.

Interaction with Other Parts of the System

• NodeDb: Represents the database abstraction layer that interacts with a local blockchain archive database file. This file’s node_db() function creates a shared instance of it.

• watch_blockchain: The core blockchain watcher function imported from the resolver::blockchain module. It likely listens to blockchain events, updates peer information, and pushes updates through channels.

• Channels (tokio::sync::watch): Facilitate inter-task communication and state updates, allowing this test to observe real-time changes in blockchain peer data.

This file acts as a consumer and validator of the blockchain watching mechanism, confirming that updates propagate correctly from the database layer through the watcher into the subscribed observers.

Visual Diagram

flowchart TD
A[Start test_proxy_list] --> B[Create self_peer_id]
B --> C[Create subscribe channel]
B --> D[Create peers channel]
C --> E[Spawn watch_blockchain task]
D --> E
E --> F[watch_blockchain reads from NodeDb]
E --> G[watch_blockchain updates subscribe_tx and peers_tx]
A --> H[Sleep 1 second]
H --> I[Read data from subscribe_rx]
I --> J[Format peer lists as strings]
J --> K[Print formatted info]

This flowchart depicts the asynchronous flow and interactions between the test function, the blockchain watcher, and the asynchronous channels used for data exchange.