A Rust reader brings habits from ownership, enums, traits, Result, modules, pattern matching, and explicit unsafe blocks. That helps with the type that carries the invariant, but the Musi page asks a narrower question: what contract should this tests as domain promises example make visible?
#[test]
fn adds_receipt_lines() {
assert_eq!(450 + 120, 570);
}let testing := import "@std/testing";
export let test () :=
testing.it("adds receipt lines", testing.toBe(450 + 120, 570));Reading Testing and Tooling from Rust
On the Musi side, Musi tests should state the domain promise first, then check the function or value that proves it. Read the shared example through Rust eyes: keep the useful instinct, then let Musi name shape, behavior, absence, and outside work in separate places.
False friend
Do not write a test that only proves syntax can be called. Make the receipt, route, badge, or parser claim visible. For a Rust reader, the trap is expecting Musi syntax to mirror Rust even when the ideas are separated differently; Musi class is closest to a Rust trait plus law text; instances play the role of implementations for behavior.
When this pays off
Use this style when a future reader needs to know which behavior broke, not only which line failed. The Rust instinct still helps here: Keep the Rust habit of asking which type carries the invariant.