mitsuhiko / insta Goto Github PK

Hi! I just upgraded to insta 0.11 and started taking advantage of the Settings struct to partition my snapshots a little more.

My tests are roughly of this shape:

let mut settings = insta::Settings::new();

let snapshot_path = Path::new(env!("CARGO_MANIFEST_DIR")).join("serve-test-snapshots");
settings.set_snapshot_path(snapshot_path);

settings.bind(|| {
    // Do the actual test

    assert_yaml_snapshot!(info, {
        ".sessionId" => "[session id]"
    });
});

When I get a snapshot failure, the .snap.new file is created in the correct place. The output tells me to run cargo insta review.

I run cargo insta review --all instead because I'm running in a workspace, but Insta tells me I have no snapshots to review:

lgreathouse /c/projects/rojo (master)
$ cargo insta review --all
done: no snapshots to review

...but I know it's lying, since my tests are still failing!

This issue also causes cargo insta test to fail, since it cannot find the snapshots that were just created. This means that the snippet recommended in the changelog to upgrade to 0.11.0 doesn't finish!

Syn's tests are slow to run in debug mode. It would help to have a --release option for cargo-insta test.

assert_snapshot_matches!("string");

results in:

error[E0308]: mismatched types
   --> ta-server/src/bits.rs:209:9
    |
209 |         assert_snapshot_matches!("string");
    |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected enum `insta::runtime::ReferenceValue`, found enum `std::option::Option`
    |
    = note: expected type `insta::runtime::ReferenceValue<'_>`
               found type `std::option::Option<std::string::String>`

It looks like the example in the crate-level docs wasn't being tested (it's marked as ignore). Instead it could have been marked as no_run so it would have still been compiled.

Great library!

The very first example in the documentation is:

cargo add --dev insta

but this fails (on 1.32.0) if you don't have cargo-edit installed. I know it's a small thing... maybe a comment in the code

# cargo install cargo-edit
$ cargo add --dev insta
$ cargo install cargo-insta

would have alerted me. Don't want to give new users an initial disappointment before all the insta fun :)

I'm working on a project that needs to snapshot multiple things for each test. I'd like to build some thin utility functions around the snapshots, but this results in them being placed within a utility folder.

I'm not sure what the mechanism might be, but I'd like to be able to specify where my snapshots are stored.

Hi! Thanks for making Insta! It's really neat!

I find myself with a lot of snapshots of the following form:

  assert_yaml_snapshot_matches!(data, @r###"given: courses
what: courses
limit: []
where: {}
do:
  lhs: Count
  op: GreaterThan
  rhs:
    Integer: 2"###);

It's kinda awkward, having the first key be on the first line instead of lined up with the rest of the YAML.

It would be nice if we could retain the leading ---, so as to achieve something like this:

  assert_yaml_snapshot_matches!(data, @r###"---
given: courses
what: courses
limit: []
where: {}
do:
  lhs: Count
  op: GreaterThan
  rhs:
    Integer: 2"###);

It looks like the --- is stripped off here:

Would you be willing to reconsider the stripping, or to bikeshed an option name?

Thanks again for making Insta!

Would you take a PR to change the inline test indentation from using ⋮ to just removing the rectangle of white space, similar to https://github.com/janestreet/ppx_expect#whitespace?

I had started on that PR but thought it worth checking first...

At the moment, insta library pulls quite a few deps. Specifically, in my Cargo.lock I see

dependencies = [
 "chrono 0.4.7 (registry+https://github.com/rust-lang/crates.io-index)",
 "ci_info 0.3.1 (registry+https://github.com/rust-lang/crates.io-index)",
 "console 0.7.7 (registry+https://github.com/rust-lang/crates.io-index)",
 "difference 2.0.0 (registry+https://github.com/rust-lang/crates.io-index)",
 "failure 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)",
 "lazy_static 1.3.0 (registry+https://github.com/rust-lang/crates.io-index)",
 "pest 2.1.1 (registry+https://github.com/rust-lang/crates.io-index)",
 "pest_derive 2.1.0 (registry+https://github.com/rust-lang/crates.io-index)",
 "ron 0.4.2 (registry+https://github.com/rust-lang/crates.io-index)",
 "serde 1.0.99 (registry+https://github.com/rust-lang/crates.io-index)",
 "serde_json 1.0.40 (registry+https://github.com/rust-lang/crates.io-index)",
 "serde_yaml 0.8.9 (registry+https://github.com/rust-lang/crates.io-index)",
 "uuid 0.7.4 (registry+https://github.com/rust-lang/crates.io-index)",
]

insta is dev-dependency, so those transtive deps don't leak into the final executable, but they still affect compile time and the size of the ./target dir, making overall CI time larger.

I think I understand why each of those dependencies is there, but, at the same time, some of them look like that could have been avoided or made optional.

Specifically:

• json, yaml and ron are kind of the same thing, perhaps serialziation formats can be opt-in?
• pestis used for redactions, but it's a heavy dependency, could redactions be made a feature?
• failure slightly out of place in the library, perhaps sticking with std::error will work?
• ci_info looks pretty entreprisy, Cargo just checks two env vars: https://github.com/rust-lang/cargo/blob/1dd02155c988707b3e12606f52b29a90c76520dd/src/cargo/util/mod.rs#L86-L89
• chrono is also heavy, and, I think, it is only used to format time in snap files. In this case, I don't know how to improve this, except for removing the time field altogether.

The new dynamic redactions feature in 0.12.0 is cool! However, it depends on the user interacting with types from the internals module, notably Redaction and Content.

Additionally, Content has some variants that are explicitly hidden from documentation that are necessary to do some dynamic redactions, like Content::NewtypeStruct.

Are these types stable? Should I depend on them in my crate using Insta, or was depending on them an unintended artifact?

I could not figure out how to have multiple redactions:

        assert_json_snapshot_matches!(
            "oci_json",
            &actual,
            { ".process.user.uid" => 42, ".process.user.gid" => 42, }
        );

error: expected expression, found `,`
   --> src/container/contained_v2.rs:407:14
    |
407 |             &actual,
    |              ^ expected expression

error: aborting due to previous error

If possible, could that be added to the README?

i'm working on a project that builds with Buck i really want to use insta for my tests, unfortunately it seems like insta expects a lot of cargo env variables to be set and at some point it shells out to cargo metadata --format-version=1 --no-deps to get that workspace_root.

would it be possible to decouple it from cargo and have all env variables set manually for non-cargo builds?
i'm happy to do the work if that something this project would consider

I am considering using insta for parser tests in Syn. Great tool!

One thing I noticed is the disruptive indentation of inline snapshots:

How do you feel about aligning the inline snapshots with the first character of the macro invocation, possibly with a margin of box-drawing or block characters?

    assert_ron_snapshot_matches!(User {
        id: 42,
        username: "peter-doe".into(),
        email: Email("[email protected]".into()),
    }, @r###"
    ░User(
    ░  id: 42,
    ░  username: "peter-doe",
    ░  email: Email("[email protected]"),
    ░)
    "###);

In the context of my use case:

#[test]
fn test_async_fn() {
    let code = "async fn process() {}";
    let syntax_tree: Item = syn::parse_str(code).unwrap();

    assert_debug_snapshot_matches!(syntax_tree, @r###"
    ░Fn(
    ░    ItemFn {
    ░        attrs: [],
    ░        vis: Inherited,
    ░        constness: None,
    ░        unsafety: None,
    ░        asyncness: Some(
    ░            Async
    ░        ),
    ░        abi: None,
    ░        ident: Ident(
    ░            process
    ░        ),
    ░        decl: FnDecl {
    ░            fn_token: Fn,
    ░            generics: Generics {
    ░                lt_token: None,
    ░                params: [],
    ░                gt_token: None,
    ░                where_clause: None
    ░            },
    ░            paren_token: Paren,
    ░            inputs: [],
    ░            variadic: None,
    ░            output: Default
    ░        },
    ░        block: Block {
    ░            brace_token: Brace,
    ░            stmts: []
    ░        }
    ░    }
    ░)
    "###);
}

I've got some tests using Insta, to test the output of templating for my webapp. On macOS these work just great, with filenames that are relevant to the test in question. (e.g. tests__no_templates.snap, tests__simple_template.snap, etc).

When I'm running the exact same build on my CI setup, which runs on Linux instead, this fails. And it fails because the filenames it is looking for are tests__main.snap, tests__main-2.snap, etc.

In both cases I'm using the latest nightly Cargo cargo 1.41.0-nightly (626f0f40e 2019-12-03) and Rust rustc 1.42.0-nightly (0de96d37f 2019-12-19), and I'm using Insta 0.12.0, with a Cargo.lock file so CI should be using the identical version. I'm also doing all of the assertions with the assert_debug_snapshot! macro from the crate.

Cheers

Hi, sorry for creating here an issue, but I think it worth.
Could you please take a look on PR ?
It is looks like insta every time creates new snapshots and dont using previous.
Could you please tell me what I'm doing wrong.
Ubuntu 18, rust 1.40

P.S. I'm not very experienced Rust programmer, so I'm sorry for taking your time.

Currently cargo insta review will only update @​r###"..."### if it is contained inside of a macro invocation whose name starts with assert_ and ends with _snapshot_matches.

That forces the same naming convention on helper macros that the calling code might want to use. For example in Syn it would be convenient to use a macro that parses tokens to syntax tree, compares against an inline snapshot, and evaluates to the parsed syntax tree as an expression in case the caller wants to do further assertions on it.

Would you foresee any problems with skipping the name check entirely and relying on finding a macro with any name spanning the right lines and with its input tokens ending in @​r###"..."### ?

When I have snapshot failures in a project that is a Cargo workspace, it's necessary to run cargo insta review --all to review snapshots outside of the default crate.

Insta does not tell the user about --all, however, and still recommends cargo insta review. This erroneously indicates that there are no snapshots to review.

Would it be a good idea to make cargo insta operate on all packages by default? This behavior matches cargo test but feels very backwards, and I forget to pass in --all about a quarter of the time I'm using Insta.

I'm trying to port a project from using a custom redaction implementation (mentioned in #73) to the new dynamic redaction system in 0.12.0.

The struct I'm trying to redact is recursive:

#[derive(Serialize, Deserialize)]
pub struct ViewedInstance {
    id: Uuid,
    children: Vec<ViewedInstance>,
}

I tried to use .id as my selector, but it only targets the top-level id field. I don't see any way to select any key named id, regardless of depth, in the documented selector syntax.

Since I'm using a dynamic redaction, I can match on Content fairly precisely to make sure I'm only impacting the correct content. My redaction function would be okay to run on all content values.

I'm trying to update a snapshot with the cargo insta review but get the error message `Incorrect function. (os error 1). It only happens when I use Git Bash on Windows. Using cmd.exe works fine.

Steps to reproduce:

1. Open Git Bash on Windows
2. Change the directory to a project that has a snapshot test
3. Modify a test so the snapshot doesn't match
4. Run cargo insta review
5. Notice the normal message that the snapshot has changed and that you get options to accept, reject or skip.
6. Notice that you cannot enter your choice because of the error message `error: Incorrect function. (os error 1).

Again, using cmd.exe works fine.

If I define a test in a file like src/foo.rs, but my tests are in a mod test block, as is convention for Rust tests, the resulting snapshots are named with test as the prefix, not foo.

For example:

// src/foo.rs

pub fn add_one(value: u32) -> u32 {
    value + 1
}

#[cfg(test)]
mod test {
    use insta::assert_yaml_snapshot;

    #[test]
    fn it_adds_one() {
        let one = add_one(0);
        assert_yaml_snapshot!(one);
    }
}

The snapshot this test produces will be src/snapshots/test__it_adds_one.snap. It should be (and would be without the mod test wrapper) src/snapshots/foo__it_adds_one.snap.

This naming is problematic when there are multiple modules in the same folder that each have snapshot tests.

When wrapping a struct in another struct ("newtype"), then it seems the redaction of fields doesn't work anymore.

#[derive(Serialize, Clone)]
pub struct User {
    id: String,
    name: String,
}

#[derive(Serialize)]
pub struct UserWrapper(User);

#[test]
fn redaction_user() {
    let user = User { id: "my-id".into(), name: "my-name".into() };
    let wrapper = UserWrapper(user.clone());

    // This works as expected
    assert_json_snapshot!(user, {
        r#".id"# => "[id]"
    }, @r###"
   ⋮{
   ⋮  "id": "[id]",
   ⋮  "name": "my-name"
   ⋮}
    "###);

    // This fails - 'id' is not redacted
    assert_json_snapshot!(wrapper, {
        r#".id"# => "[id]"
    }, @r###"
   ⋮{
   ⋮  "id": "[id]",
   ⋮  "name": "my-name"
   ⋮}
    "###);
}

Using version 0.11.0

Can we get a new release so that it works on windows?

Recently the ty module in rust-analyzer was extracted to a separate crate; afterwards I couldn't use cargo insta review in the workspace root anymore, it always just quit with error: No such file or directory (os error 2). I now finally got annoyed enough with that that I ran it with strace, and it turns out the problem was a pending snapshot file that had no corresponding source file anymore. It would be nice if such a file just got ignored.

This is easy to reproduce: E.g. in rust-analyzer, just do touch crates/ra_hir/src/ty/.tests.rs.pending-snap and try to run cargo insta review.

I've run --force-update-snapshots today. It worked flawlessly for most of the cases, expect this single problem:

Here, insta adds leading indentation to the otherwise blank line, which doesn't work great with editors which strip trailing ws on save.

I just ran insta with some changes that caused the comparison to fail. I then reverted these changes and the test passed again. However, the .new files from the broken state were still there. I compared them with the approved snapshot until I noticed that the .new one did not represent my code anymore, since I had reverted it.

I did not expect the .new files to refer to previous runs. I expect them to refer to the latest run. If the comparison fails, then the .new files will be overwritten as expected. It is only when the test passes anew while having previously failed that this issue occurs.

I would suggest removing existing .new files when a test passes to prevent this mistake of assuming they represent the current state of the code.

I'm working on adding support for force upgrading snapshots even if they match but the creator/created fields are changing unnecessarily at this point even for snapshots that would otherwise be perfect matches. I'm wondering if there is a lot of value of actually having these fields there.

I'm thinking of just removing them which would also drop the chronos dependency (refs #58).

@max-sixty thoughts?

Hello!

If this is expected behaviour then please ignore, but if I have a workspace where members have insta tests, then I have to run cargo insta review in every directory, as opposed to being able to run it in the workspace, which gives the title output.

It's useful for debugging, since I have logs I want to look at, and the diff is long.

Hi! I am using insta inside a workspace, and snapshot gets a wrong location: rust-lang/rust-analyzer@ce9ecdf

The problem I think is that file!() returns a relative to the workspace root path to the file, while tests, when run, get the cwd of a package

That is, this:

        eprintln!("file!() = {:?}", file!());
        eprintln!("std::env::current_dir() = {:?}", std::env::current_dir());

prints this:

file!() = "crates/ra_ide_api_light/src/lib.rs"
std::env::current_dir() = Ok("/home/matklad/projects/rust-analyzer/crates/ra_ide_api_light")

and joining the two together gives the repetition of crates/ra_ide_api_light.

I think the solution is to call env!("CARGO_MANIFEST_DIR") from the insta macro, and use that as a base path, and not the cwd of the test binary.

I'm writing a test harness using insta that does test case discovery itself. It would be great if you could expose a Result-giving API (roughly runtime::assert_snapshot?) to allow usecases like this to have a bit more control.

Feel free to shut this down, but when used frequently, assert_snapshot_matches or assert_display_snapshot_matches is a lot of characters (latter is 31, or ~40% of a full line).

Any interest in shortening to assert_snapshot / assert_display_snapshot / etc? There's no other viable comparison than a match / eq, so it could be OK to make that implicit.

(And we'd keep the existing as aliases)

I'm building a couple tools using Insta, and I want to package up the code I need to properly transform my data into a snapshottable form, and then run Insta's snapshot assertion functions on that data.

However, Insta puts those snapshot files relative to where the utility functions are defined, not relative to the test that's actually invoking them!

• My utility function is in src/tree_view.rs
• The code using the utility is in src/commands/serve.rs in a mod named test.
• The snapshots from that test end up in src/snapshots with a name like tree_view__my_snapshot_name.snap.

I would expect the snapshots to instead be put into src/commands/snapshots and have a name like serve__my_snapshot_name.snap.

On windows, / for paths should be used to avoid useless diffs when running on Unix later.

https://github.com/rust-analyzer/rust-analyzer/pull/603/files#diff-f2b4e4198531fe943a7da6a45e56161eR5

Repro on the file-not-found branch here: https://github.com/jonas-schievink/instabug/tree/file-not-found

Running cargo test will fail as expected, and touch the .snap.new file. Then, running cargo insta review will correctly show the diff between the versions. However, accepting the new snapshot just shows the same snapshot again, and accepting it again will fail with error: No such file or directory (os error 2).

For some reason this is caused by build.rs. Removing it fixes the issue.

I have a pattern of naming my snapshots the same as the test name. Would it be possible for insta to infer the snapshot name from the name of the test, perhaps while still allowing a user to optionally pass in a different name if they'd like?

When rustfmt is not installed, the output ends with a panic:

thread 'block::tests::outputs_a_block_with_correct_indentation' panicked at 'byte index 14 is out of bounds of ``', src/libcore/str/mod.rs:2092:9
note: Run with `RUST_BACKTRACE=1` for a backtrace.

There is an error near the top of the output, but it's easy to miss:

error: 'rustfmt' is not installed for the toolchain 'stable-x86_64-apple-darwin'
To install, run `rustup component add rustfmt`

Could something like this error be printed instead of the out of bounds panic?

I'm working with graph traversal algorithms and snapshotting graph representations would make tests so much simpler.

one thing that i'm struggling with is snapshotting unsorted collections (like HashSet or HashMap)

for example if i snapshot a random HashSet, next time i run the test i'd get something like this:

the test fails, even though it's practically the same set

I'm new to rust and not sure if it's possible to overwrite serialize traits in test environment to sort them, but maybe as an alternative something can be done to a resulting json string

I can't work out the cause of this, but here's the issue:

#[test]
fn test_unicode_inline() {
    use insta::assert_snapshot_matches;
    assert_snapshot_matches!("a 😀oeu", @"");
}

After accepting, this is the replacement:

#[test]
fn test_unicode_inline() {
    use insta::assert_snapshot_matches;
    assert_snapshot_matches!("a 😀oeu", @"")"a 😀oeu"
}

I'm having trouble debugging the FilePatcher struct given it's not trivial to set up a test case for it - any tips welcome.

Currently snapshots are stored in a separate files which is super-convenient for updating them, but makes reading the tests more difficult, because you don't have a test code and tests result near each other.

One could imagine a three argument form of assert_debug_snaphot_mathes, where the third argument is the text of the snapshot. It seems like this won't work, because updating the snapshot will require updating the source code, but perhaps it is possible? Snapshots have a well-defined header, so just grepping src for them should perhaps work? This sounds like a terrible idea, but I can see myself using it :)

If we intentionally place a newline at the end of a string (i.e. testing a snapshot of terminal output), inline snapshot comparisons will work as expected if we manually populate the inline snapshot. However if we run cargo insta review and accept the output, the snapshot fails because the last newline is removed.

It looks like the newline is removed intentionally to allow placing "### on a separate line, but perhaps we can distinguish between these cases?

For example, if we have a simple test with a snapshot that hasn't been populated yet:

insta::assert_snapshot_matches!("\n", @"");

Running cargo insta review notes the difference correctly:

-old snapshot
+new results
─────────────
"\n"
──────┬──────
    1 ⋮+
    2 ⋮+
──────┴──────

If we accept this output, the snapshot is unchanged and remains as "". If we manually place "\n" as the snapshot then everything works again.

When I first started using the redactions API, I had trailing commas (similar mistake to #12?), which gave me a huge, unfriendly error message!

Input:

assert_yaml_snapshot!(info, {
    ".sessionId" => "[session id]",
});

Error output:

error: expected one of `.`, `;`, `?`, `}`, or an operator, found `=>`
  --> rojo-test\src\serve_test.rs:31:26
   |
31 |             ".sessionId" => "[session id]",
   |                          ^^ expected one of `.`, `;`, `?`, `}`, or an operator here

error[E0277]: the trait bound `insta::runtime::ReferenceValue<'_>: std::convert::From<std::option::Option<librojo::web::interface::ServerInfoResponse>>` is not satisfied
  --> rojo-test\src\serve_test.rs:30:9
   |
30 | /         assert_yaml_snapshot!(info, {
31 | |             ".sessionId" => "[session id]",
32 | |         });
   | |___________^ the trait `std::convert::From<std::option::Option<librojo::web::interface::ServerInfoResponse>>` is not implemented for `insta::runtime::ReferenceValue<'_>`
   |
   = help: the following implementations were found:
             <insta::runtime::ReferenceValue<'a> as std::convert::From<&'a str>>
             <insta::runtime::ReferenceValue<'a> as std::convert::From<std::option::Option<&'a str>>>
             <insta::runtime::ReferenceValue<'static> as std::convert::From<insta::runtime::AutoName>>
             <insta::runtime::ReferenceValue<'static> as std::convert::From<std::option::Option<std::string::String>>>
             <insta::runtime::ReferenceValue<'static> as std::convert::From<std::string::String>>
   = note: required because of the requirements on the impl of `std::convert::Into<insta::runtime::ReferenceValue<'_>>` for `std::option::Option<librojo::web::interface::ServerInfoResponse>`
   = note: this error originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info)

Points to https://github.com/mitsuhiko/insta/blob/master/struct.Settings.html

The struct isn't in on the docs yet – can link there when it is

It's very possible I'm missing something, but at the moment do we have some potential confusion for users between command line args and the INSTA_UPDATE env variable?

Specifically, I think most of the options in INSTA_UPDATE can't be replicated by command line args passed to cargo insta test except for:

• INSTA_UPDATE=always is equivalent to passing --accept
• --force-update-snapshots doesn't have an equivalent (though maybe makes sense as it's a one-off)

Should we make INSTA_UPDATE=new and INSTA_UPDATE=no available as command line args? And, if I've understood the always <> accept equivalence, unify the names, or at least offer the same name as an option?

Something like --update=new / --update=always / --update=force?

Hello! I work on Gitpod, and I just wanted to make sure that compiling Insta works well in Gitpod.

I basically just tried cargo build and cargo test, but the latter failed and I don't understand why:

error[E0432]: unresolved import `insta::assert_serialized_snapshot_matches`
 --> tests/test_basic.rs:3:44
  |
3 | use insta::{assert_debug_snapshot_matches, assert_serialized_snapshot_matches};
  |                                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ no `assert_serialized_snapshot_matches` in the root. Did you mean to use `assert_debug_snapshot_matches`?

error: cannot determine resolution for the macro `assert_serialized_snapshot_matches`
  --> tests/test_basic.rs:12:5
   |
12 |     assert_serialized_snapshot_matches!("serialized_vector", vec![1, 2, 3]);
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: import resolution is stuck, try simplifying macro imports

error: aborting due to 2 previous errors

For more information about this error, try `rustc --explain E0432`.
error: Could not compile `insta`.

E0432 seems to suggest adding extern crate insta; but that's already present:

I've made a "Gitpod snapshot" to demonstrate the issue (clicking on it will take you to an online workspace where Insta was cloned, cargo build was run, and cargo test will run and fail):

Could you please help me understand this issue?

I have a project that's using insta to snapshot a tree. Each node in the tree has an ID that's randomly generated, and may hold references to other nodes via IDs.

Insta lets me redact all IDs with an expression like "[.id]" = "[redacted id]", but this is a very heavy hammer. I lose any properties that happen to also have a key named id, and I can no longer snapshot that the inter-node relationships are correct.

It's possible in my case to turn those IDs into something deterministic, however, like using an incrementing number and deterministic tree traversal.

I'm okay generating a batch of redactions up-front with the settings API. Turning the selector argument of Settings::add_redaction into a trait and providing a couple implementations could open up something like:

settings.add_redaction(
	Selector::new()
		.key_equal("id")
		.value_display_equal("75e60f48-d251-4717-969f-904f655581a8"),
	"[ID 0]",
);

Alternatively, being able to provide a callback would let me use the maps I generate dynamically instead of statically handing over a bunch of redactions to Insta:

settings.add_map_redaction(move |(key, value)| {
	if key == "id" {
		if let Some(new_value) = id_map.get(value.to_string().parse()) {
			return InstaData::String(new_value);
		}
	}

	value
});

Currently cargo insta in workspace prints

error: Cargo.toml appears to be a workspace root but not a package by itself. Enter a package folder explicitly or use --all

I wonder if it could just work as if --all was there?

I believe currently Cargo works this way uses implied --all as well, although it used to emit the similar "hey, rerun me with --all" kind of error.

git on windows may change \n to \r\n and that I think might lead to comparison failure:

I can see that snapshot names include module name (typically just test). I think there might be conflicts when a couple of modules at the same level have a "test" submodule with identical test functions. For example:

mod1.rs has a submodule "test" with a test "test_foo()"

and

mod2.rs has a submodule "test" with a test "test_foo()".

There are few ways to avoid this situation: put modules into subdirectories, rename test submodules or test functions. But I think it could be the most convenient to have snapshot names include super modules too: mod1__test__foo.snap, mod2__test__foo.snap, etc.

Reproduction: https://github.com/jonas-schievink/instabug

It contains a test where an empty line was added between two lines of output.

If you run cargo test, this is displayed:

---- tests::bla stdout ----
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Snapshot Differences ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Snapshot file: src/snapshots/tests__bla.snap
Snapshot: bla
Source: src/lib.rs:7
Old: Wed,  6 Feb 2019 11:58:22 +0100
New: Wed,  6 Feb 2019 12:00:47 +0100

-old snapshot
+new results
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
r#"
t line
nd line
──────┬───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
──────┴───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
To update snapshots run `cargo insta review`
  stored new snapshot /home/jonas/dev/instabug/src/snapshots/tests__bla.snap.new

The added line doesn't show up at all, which seems like a bug (the same happens when running cargo insta review).

(also, the formatting of the snapshot expression seems kind of broken - t line nd line)