A Lua reader brings habits from tables, metatables, nil, coroutines, embedding, modules, and small runtime boundaries. That helps with simple data and host/runtime edges without much ceremony, but the Musi page asks a narrower question: what contract should this tests as domain promises example make visible?
it("adds receipt lines", function()
assert.are.equal(570, 450 + 120)
end)let testing := import "@std/testing";
export let test () :=
testing.it("adds receipt lines", testing.toBe(450 + 120, 570));Reading Testing and Tooling from Lua
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 Lua 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 Lua reader, the trap is letting table shape, missing fields, and behavior conventions blur together; Musi class is not a metatable pattern; records/data hold table-like shape, classes/instances name promised behavior.
When this pays off
Use this style when a future reader needs to know which behavior broke, not only which line failed. The Lua instinct still helps here: Keep the Lua habit of using small names and simple values.