A C reader brings habits from headers, translation units, pointers, arrays, errno, sentinel returns, and small functions that trust callers. That helps with cost, layout, and the exact boundary where bytes cross into code, but the Musi page asks a narrower question: what contract should this tests as domain promises example make visible?
void test_receipt_lines(void) {
assert(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 C99
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 C99 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 C reader, the trap is treating convention as a contract; Musi class is not a C struct with function pointers; records/data carry shape, classes name behavior a type can provide.
When this pays off
Use this style when a future reader needs to know which behavior broke, not only which line failed. The C99 instinct still helps here: Keep the C habit of asking where memory, symbols, and failures come from.