atrium-api 0.26.0

//! Fidelity tests for the code generated by `atrium-codegen`.
//!
//! These assert properties of the *generated code itself* — the shape of the
//! `Collection` impl and its agreement with `KnownRecord` — so they are not
//! coupled to the contents of any particular lexicon revision.

#![cfg(feature = "namespace-appbsky")]

use atrium_api::app::bsky::actor::ContentVisibilityDeclaration;
use atrium_api::record::KnownRecord;
use atrium_api::types::Collection;

/// `app.bsky.actor.contentVisibilityDeclaration` is the first record whose NSID
/// leaf is camelCase, and it broke an assumption in codegen: the NSID was
/// rebuilt from the snake_case'd file stem, so the record never matched its own
/// schema and got no `Collection` impl. `KnownRecord` is keyed on schema ids, so
/// it *did* gain the variant — leaving downstream crates with an arm they could
/// not satisfy.
#[test]
fn camel_case_record_nsid_is_generated_verbatim() {
    const NSID: &str = "app.bsky.actor.contentVisibilityDeclaration";

    // Naming `NSID` at all requires the `Collection` impl to exist; the
    // assertions require it to carry the NSID verbatim, rather than a
    // snake_case'd or otherwise mangled form.
    assert_eq!(ContentVisibilityDeclaration::NSID, NSID);
    assert_eq!(ContentVisibilityDeclaration::nsid().as_str(), NSID);
}

/// The `Collection` and `KnownRecord` halves must *agree* on the record type,
/// not merely both exist. This is never called: it is a compile-time assertion,
/// and fails to build if the `Collection` impl disappears again or its `Record`
/// drifts from the type the corresponding `KnownRecord` variant holds.
#[allow(dead_code)]
fn collection_record_is_the_known_record_payload(
    record: <ContentVisibilityDeclaration as Collection>::Record,
) -> KnownRecord {
    KnownRecord::AppBskyActorContentVisibilityDeclaration(Box::new(record))
}