A TypeScript reader brings habits from objects, structural types, unions, undefined, promises, imports, npm packages, and prototype-shaped history. That helps with flexible shapes and fast feedback from type tooling, but the Musi page asks a narrower question: what contract should this tests as domain promises example make visible?
test("adds receipt lines", () => {
expect(450 + 120).toBe(570);
});let testing := import "@std/testing";
export let test () :=
testing.it("adds receipt lines", testing.toBe(450 + 120, 570));Reading Testing and Tooling from JavaScript/TypeScript
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 JavaScript/TypeScript 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 TypeScript reader, the trap is assuming runtime object shape and compile-time behavior contract are the same thing; Musi class is not a JS constructor or TS class; it is a behavior contract implemented separately from record/data shape.
When this pays off
Use this style when a future reader needs to know which behavior broke, not only which line failed. The JavaScript/TypeScript instinct still helps here: Keep the TypeScript habit of reading the shape before reading implementation details.