test.rs

Overview

This file contains unit tests focused on verifying the correctness of configuration deserialization and validation within the system. Specifically, it tests the parsing and instantiation of network and general configuration structs from JSON strings. The tests ensure that the configuration parsing logic correctly maps JSON fields to Rust types, such as socket addresses and paths, and validates default values for optional fields.

The module is conditionally compiled and only included during test builds (#[cfg(test)]), serving as part of the project's internal verification suite.

Module: tests

Purpose

The tests module encapsulates test cases related to configuration parsing for network and local settings. It uses Rust's built-in test framework and the anyhow crate for error handling in test functions.

Imports

• std::net::SocketAddr: For validating IP address and port combinations.

• std::path::PathBuf: For handling filesystem paths.

• std::time::Duration: For verifying time duration values.

• crate::config::{Config, NetworkConfig}: The configuration structs under test.

• crate::node::NodeIdentifier: Used to verify node identifiers in the configuration.

Test Functions

test_network_config() -> anyhow::Result<()>

Description

Tests deserialization of a JSON string into a NetworkConfig struct. It verifies that various network-related fields are parsed correctly and that default values are properly set when not explicitly provided.

Parameters

• None.

Returns

• anyhow::Result<()>: Returns Ok(()) if the test passes; otherwise, the test framework reports a failure.

Behavior and Assertions

• Parses a JSON string representing network configuration.

• Checks that the bind address defaults to 127.0.0.1:8500 despite the input specifying node_advertise_addr as 0.0.0.0:8500.

• Validates node_advertise_addr and api_addr addresses.

• Confirms that gossip_seeds and static_storages lists are empty.

• Ensures that gossip_listen_addr defaults to 127.0.0.1:10000.

• Confirms send_buffer_size is set to 1000.

Usage Example

let config_str = r#"{
    "node_advertise_addr": "0.0.0.0:8500",
    "api_addr": "127.0.0.1:8600",
    "api_advertise_addr": "http://node0:8600",
    "gossip_seeds": []
}"#;
let config: NetworkConfig = serde_json::from_str(config_str)?;
assert_eq!(config.bind, SocketAddr::from(([127, 0, 0, 1], 8500)));

test_config_load() -> anyhow::Result<()>

Description

Tests deserialization of a comprehensive JSON configuration string into the main Config struct. This test verifies correct parsing of both network and local configuration sections, including addresses, file paths, node identifiers, and global timing parameters.

Parameters

• None.

Returns

• anyhow::Result<()>: Returns Ok(()) upon successful validation; otherwise, the test framework marks failure.

Behavior and Assertions

• Parses a JSON string with nested network and local configurations.

• Validates multiple network addresses and confirms empty seeds and storages.

• Checks local node identifier parsing against a known constant value.

• Verifies file paths for blockchain config, keys, zerostate, and external state sharing directory.

• Confirms default or specified values for parallelization, cache sizes, and rate limits.

• Validates global timing parameters such as block production intervals and synchronization thresholds.

Usage Example

let config_str = r#"{
    "network": {
        "node_advertise_addr": "0.0.0.0:8500",
        "api_addr": "127.0.0.1:8600",
        "api_advertise_addr": "https://node0:8600",
        "gossip_seeds": []
    },
    "local": {
        "node_id": "81a6bea128f5e03843362e55fd574c42a8e457dd553498cbc8ec7e14966d20a3",
        "blockchain_config_path": "../bc_config.json",
        "key_path": "key1.json",
        "zerostate_path": "./zerostate",
        "external_state_share_local_base_dir": "/tmp",
        "parallelization_level": 20,
        "split_state": false,
        "block_keeper_seed_path": "block_keeper.keys.json",
        "block_cache_size": 20,
        "state_cache_size": 10,
        "message_storage_path": "message_strage",
        "rate_limit_on_incoming_block_req": 1000,
        "ext_messages_cache_size": 10,
        "node_wallet_pubkey": "hex_string"
    }
}"#;
let config: Config = serde_json::from_str(config_str)?;
assert_eq!(config.local.blockchain_config_path, PathBuf::from("../bc_config.json"));

Implementation Details and Algorithms

• Deserialization leverages the serde_json crate to convert JSON strings into Rust structs.

• The tests validate both explicit values and default fallbacks, ensuring robust parsing logic in the corresponding configuration modules.

• The SocketAddr::from method is used to create IP address and port tuples for comparison.

• The NodeIdentifier::some_id() method (likely a placeholder or factory method) is used to compare against a parsed node ID.

• Duration values are checked using Duration::from_secs to verify timing configurations.

Interaction with Other System Components

• This test module depends on the Config and NetworkConfig structs defined in the config module, which handle the actual configuration schema and parsing logic.

• It also references NodeIdentifier from the node module for validation of node identity fields.

• The tests indirectly confirm that configuration loading, a critical step for the system startup and node initialization processes, behaves as expected.

• These tests ensure that other components relying on configuration values receive properly parsed and validated data structures, supporting consistent node/network behavior.

Visual Diagram: Test Module Structure and Function Relationships

flowchart TD
TestsModule[tests mod]
TestNetworkConfig["test_network_config()"]
TestConfigLoad["test_config_load()"]
ConfigStruct[Config Struct]
NetworkConfigStruct[NetworkConfig Struct]
NodeIdentifierClass[NodeIdentifier]
TestsModule --> TestNetworkConfig
TestsModule --> TestConfigLoad
TestNetworkConfig --> NetworkConfigStruct
TestConfigLoad --> ConfigStruct
TestConfigLoad --> NodeIdentifierClass

This flowchart illustrates the tests module containing two test functions. Each test function depends on configuration-related structs or classes for validation. The dependencies indicate how the tests interact with the configuration and node identity components of the system.