ArchUnitRust

Write the sentence your team already says — the API must not reach the database — as an ordinary Rust test, and let cargo test show the dependency evidence when the code disagrees.

use archunit::{assert_passes, project_files};

#[test]
fn api_does_not_reach_database() {
    let rule = project_files()
        .in_path("src/api/**")
        .should_not()
        .depend_on_files()
        .in_path("src/database/**");

    assert_passes!(rule);
}

There is no configuration file, registry, or test adapter. A rule is an immutable value. Building one reads nothing; assert_passes! or Checkable::check locates the Cargo project, extracts the graph, and evaluates the rule.

Install

ArchUnitRust currently installs from Git as a development dependency and requires Rust 1.85 or newer:

cargo add --dev --git https://github.com/LukasNiessen/ArchUnitRust archunit

Cargo records the resolved commit in Cargo.lock. The package is not on crates.io yet, so a versioned registry dependency is not currently an honest installation instruction.

Your first rule

Put architecture tests in tests/architecture.rs, change the paths in the opening example to match the project, then run:

cargo test --test architecture

Three details matter before the second rule:

• Selectors match normalized, project-relative identifiers. Plain strings are complete, case-sensitive globs. Read patterns and identifiers before translating filesystem assumptions into rules.
• An empty scope fails. A misspelled or stale selector returns an EmptyTestViolation rather than a false green result. Intentional empty scopes require CheckOptions.
• Violations are data; execution failures are errors. Checkable::check returns Result<Vec<Violation>, ArchUnitError>. The assertion macro turns either a non-empty violation list or an error into one useful test failure.

Where to go next

• The grammar explains entry points, scopes, moods, conditions, and terminals.
• Patterns and identifiers defines glob behavior and selector targets.
• The files family covers dependencies, cycles, naming, placement, and callbacks.
• The layers family turns named folders into one dependency policy.
• The slices family captures components and checks or draws their relationships.
• The metrics family measures Rust code and turns values into thresholds or zones.
• Dependency-graph reports renders the analyzed graph in six formats.
• Running a rule covers options, logging, ignored imports, results, and failures.
• How it works describes the source-to-report pipeline and repository boundaries.

The generated Rust API reference sits beside this guide. The source code and its public doc comments remain the authority when a guide explanation and a symbol signature differ.