SRI Integration Test Framework

[plebhash]

SRI Message Generator (MG) was originally conceived as a tool for interoperability tests, where different implementations of the Stratum V2 protocol could be tested against each other.

With time, the SRI community started using MG tests as a tool for Continuous Integration (CI).

There’s been some discussion in the SRI community about the possibility of partially replacing some MG tests with a new framework for Integration Tests. That framework would take inspiration from well established projects in the Bitcoin community such as LDK and Fedimint.

It would allow MG to be limited to its originally intended purpose of interoperability testing, while also giving more flexibility and agility with regards to how CI is done for development of the SRI application layer.

This issue proposes a plan for how this migration will be executed. First, we propose a roadmap for the actual development of the new Integration Test Framework. Then, we propose a roadmap for the migration of the CI stack from MG tests into Integration Tests.

SRI Integration Test Framework

This is the proposed roadmap for the creation of the new SRI Integration Test Framework. It is split in multiple stages. Some stages could be potentially executed in parallel (e.g.: 1 + 2 and 2 + 3), while others need to be executed sequentially (e.g.: 1, then 3... and 3, then 4).

1. Initial roles refactoring

• Restructure Roles as a prepration for integration tests #1093

Note: this is an exception that we are making against premature roles refactoring, for which the proper roadmap is still under early brainstorming via #1069 and tasks will be structured via #1117

The changes being introduced here are relatively superficial and should not affect the overall architecture of roles.

2. Bitcoind integration

• SRI Integration Test Framework: bitcoind #1119

3. Message synchronization primitives

• SRI Integration Test: Message Synchronization Primitives #1122

4. CI migration: MG to Integration tests

• CI migration: MG to Integration/Unit Tests #1121

[rrybarczyk]

Inside a single crate

Here is the standard for creating integration tests in a Rust-y way on a per-crate basis. Cargo automatically recognizes tests inside the tests folder and runs them when cargo test is executed.

Integration Tests in a Rust Library

In a Rust library, integration tests are focused on testing the public API. The integration tests import the library just like any external crate and test its public functions.

Project Structure

.
├── src
│   └── lib.rs
└── tests
    └── test_lib.rs

Example

extern crate my_lib;

#[test]
fn test_public_function() {
    let result = my_lib::my_public_function();
    assert_eq!(result, expected_value);
}

Integration Tests in a Rust Binary

In a Rust binary, integration tests typically involve testing the public interface of the binary—usually by running the binary with certain input and checking the output or side effects.

Project Structure

.
├── src
│   └── main.rs
└── tests
    └── test_cli.rs

Example

use std::process::Command;

#[test]
fn test_output_of_binary() {
    let output = Command::new(env!("CARGO_BIN_EXE_my_binary"))
        .arg("--help")
        .output()
        .expect("Failed to run binary");

    assert!(output.status.success());
    let stdout = String::from_utf8_lossy(&output.stdout);
    assert!(stdout.contains("Usage"));
}