A C++ reader brings habits from RAII, overload sets, templates, references, optional values, exceptions, and object hierarchies. That helps with ownership stories, value categories, and compile-time abstractions, but the Musi page asks a narrower question: what contract should this tests as domain promises example make visible?
TEST(Receipt, AddsLines) {
EXPECT_EQ(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 C++17
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 C++17 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 turning every Musi value into a class-shaped design; Musi class is closer to a concept or trait than a C++ class; records/data store shape, instances satisfy behavior.
When this pays off
Use this style when a future reader needs to know which behavior broke, not only which line failed. The C++17 instinct still helps here: Keep the C++ habit of asking which operation is generic and which value owns shape.