A Python reader brings habits from names, dictionaries, classes, protocols, exceptions, None, imports, and duck typing. That helps with code around domain words before machinery, but the Musi page asks a narrower question: what contract should this tests as domain promises example make visible?
def test_adds_receipt_lines():
assert 450 + 120 == 570let testing := import "@std/testing";
export let test () :=
testing.it("adds receipt lines", testing.toBe(450 + 120, 570));Reading Testing and Tooling from Python
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 Python 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 Python reader, the trap is trusting runtime convention where Musi expects a visible type or effect; Musi class is closer to an explicit protocol/typeclass than a Python class with attributes and methods.
When this pays off
Use this style when a future reader needs to know which behavior broke, not only which line failed. The Python instinct still helps here: Keep the Python habit of naming the real-world thing first.