Snapshot tests

[killercup]

Did we ever talk about snapshot tests? I don't recall, and I didn't find an issue in this or the assert_{cmd,cli} repos.

The idea is this: Instead of manually writing predicate::path::eq_file(Path::new("some.file")).utf8().unwrap();, you'd have a predicate::eq_snapshot!() macro that expands to a uniq filename predicate with the ability to create that file with the content it gets on the first test run or when using RECORD_SNAPSHOTS=1 or something similar.

[epage]

Good idea. While "golden state" tests are brittle, they can be useful and making it easier to update them would be a big help.

We'll also want to look into this for #33. The main impact of #33 on this issue is ensuring we have good names for both of them.

I'm assuming the snapshots would be kept under revision control.

Options for where to store

• Fixed location under tests/fixtures.
• Require the path be specified
• Use a builder for this (e.g. predicate::eq_snapshot!().from("tests/fixtures")) with a default location

Next, what is the snapshot's filename

• Manually specify it
• Use the file and line macros
  • This won't work if the macro is used in a test helper
  • This is brittle because the file names will change with the smallest test change
  • If all snapshots are dumped in an isolated directory, the workflow can just be to git rm * && cargo test && git add *
• Using a function name macro when / if its available (see RFC: Add "function name macro" rust-lang/rfcs#466 / Macro that expands into string holding function name (or module path, etc) rust-lang/rfcs#1743) would be less brittle but only allow one per test
• Use a builder for specifying it with a default

eq_snapshot would probably want a .utf8() like eq_file so we know when can provide more useful failure messages.

Any other API considerations?

[epage]

See insta for ideas we could pillage
https://crates.io/crates/insta