A Java reader brings habits from packages, classes, records, interfaces, exceptions, annotations, streams, and long-lived APIs. That helps with contracts, visibility, and maintainable names, but the Musi page asks a narrower question: what contract should this tests as domain promises example make visible?
@Test
void addsReceiptLines() {
assertEquals(570, 450 + 120);
}let testing := import "@std/testing";
export let test () :=
testing.it("adds receipt lines", testing.toBe(450 + 120, 570));Reading Testing and Tooling from Java
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 Java 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 Java reader, the trap is reading Musi class as a nominal object type with constructors and fields; Musi class is a behavior contract supplied by instances; records and data model object shape.
When this pays off
Use this style when a future reader needs to know which behavior broke, not only which line failed. The Java instinct still helps here: Keep the Java habit of naming APIs for future readers.