{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiejnfqdepkaw2f2fnfwgexzvgn57hss64vnw3xokjg4pdhjdfrcle",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3miyq6c7ce4a2"
  },
  "path": "/t/change-error-message-of-a-failing-assert-eq/24118?page=2#post_25",
  "publishedAt": "2026-04-07T13:45:08.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "snapbox",
    "started",
    "Snapbox parameter order (expected, actual) breaks common convention · Issue #226 · assert-rs/snapbox · GitHub",
    "@Muscraft",
    "pretty_assertions",
    "similar-asserts",
    "inline snapshots"
  ],
  "textContent": "I appreciate the ideas mentioned\n\n  * custom names for the sides\n  * capturing the expressions for the sides\n\n\n\nI have an anecdote that can help add some flavor to this conversation. Not saying it means we have to go a particular direction.\n\nI maintain a snapshotting library, snapbox. You can think of it as a mix of `expect-test`, `assert_cmd`, and `assert_fs` (I maintain the latter two also).\n\n`snapbox` started with:\n\n  * `assert_data_eq!(expected, actual)`\n  * `OutputAssert::stdout_eq(expected)`\n  * `Assert::eq(expected, actual)`\n  * `Assert::subset_eq(expected_root, actual_root` (for asserting that `expected_root` directory has a subset of the files of `actual_root` and those files are eq)\n\n\n\n**Note:** As a reminder, as a snapshotting library, the order is not just visual but also affects whether it can detect if it is given a snapshot, a source file that it is allowed to mutate when \"blessing\" the current output.\n\nBecause a failed assertion is shown as a diff, this was meant to mirror `diff expected actual`. There might have also been a grammatical aspect to `Assert::subset_eq`.\n\nDespite the analog to `diff expected actual`, I was regularly confused by this. `OutputAssert` also doesn't align with this order.\n\nA user also opened an issue about this at Snapbox parameter order (expected, actual) breaks common convention · Issue #226 · assert-rs/snapbox · GitHub. In that, I looked at some prior art\n\n> Then in talking over the above with @Muscraft that led to \"why is there a preference for one over the other\" and this got me looking at prior art\n>\n>   * rust only has `(left, right)`\n>   * pretty_assertions maintains the concept of `(left, right)` and lines up with `(expected, actual)` for how we show the diff\n>     * same for similar-asserts\n>   * insta inline snapshots do `(actual, snapshot)`\n>\n\n\nSince then, we've switched the order for non-directory assertions:\n\n  * `assert_data_eq(actual, expected)`\n  * `OutputAssert::stdout_eq(expected)`\n  * `Assert::eq(actual, expected)`\n  * `Assert::subset_eq(expected_root, actual_root` (I assume for grammar reasons? also not as commonly used)\n\n\n\nSince that change, `snapbox` has replaced cargo's bespoke assertions. I've not had any confusion and I've not heard of any confusion.",
  "title": "Change error message of a failing `assert_eq!`"
}