Crate rtb_test_support 

Test-only helpers for constructing an rtb_app::app::App without the full rtb_cli::Application::builder wiring.

What this crate provides

A fluent TestAppBuilder for tests that need an App without the full rtb-cli lifecycle (logging, miette hook install, signal handlers). Promoted to downstream crates that want a consistent test-helper API — a replacement for the bare App::for_testing in rtb-app.

Scope and honesty about sealing

The builder is gated behind a sealed-trait pattern (TestWitness implements a crate-private Sealed trait) — so a crate that depends on rtb-test-support is making its intent visible in its Cargo.toml. Placing rtb-test-support only in [dev-dependencies] prevents a production binary from reaching the builder through an accidental imports.

It is not watertight access control. rtb_app::App has pub fields (see the rtb-app v0.1 spec open questions), so any crate that depends on rtb-app can also construct an App via struct-literal. The seal is a speed bump, not a fence. Post-0.1 a pub(crate) field refactor + accessor methods would close this; for v0.1, rtb-test-support is the promoted test-helper entry point for new downstream tests.

Usage

// In Cargo.toml:
// [dev-dependencies]
// rtb-test-support = { path = "../rtb-test-support" }

use rtb_test_support::{TestAppBuilder, TestWitness};

let app = TestAppBuilder::new(TestWitness::new())
    .tool("mytool", "1.0.0")
    .build();

Structs

TestAppBuilder

Fluent builder for a test-only App.

TestWitness

A zero-sized witness that the caller depends on rtb-test-support. Passing a TestWitness to TestAppBuilder is how the sealing pattern unlocks the bypass constructor.