-
-
Notifications
You must be signed in to change notification settings - Fork 92
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wrong function name in snapshot when insta::assert_*_snapshot is in a other function #357
Comments
Unfortunately the thread name does not work. That's what insta did originally but sadly it breaks in some scenarios and I had to change this. While one of the major blockers was resolved, the max length limit still applies on linux and you can trivially run into it. For some history see #105 |
Ok, I can see your point. But I cannot understand the issue related to the max length. Now the fix for single thread test is fixed on stable also and follow code works non my linux mod aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa {
mod aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa {
mod aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa {
mod aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa {
mod aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa {
mod aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa {
mod aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa {
#[test]
fn feature() {
let path = std::thread::current().name().unwrap().to_owned();
let name = path.rsplit_once("::").unwrap().1;
assert_eq!("feature", name)
}
}
}
}
}
}
}
} mdamico@miklap:~/dev_random/thread_name_test$ cargo test --release -- --test-threads=1
Finished release [optimized] target(s) in 0.00s
Running unittests src/main.rs (target/release/deps/thread_name_test-0ec132d327548f97)
running 1 test
test aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa::aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa::aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa::aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa::aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa::aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa::aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa::feature ... ok
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s |
Anyway I think that to make work the integration between Thx |
I'm not sure under which circumstances one runs into the thread name limit. It's technically 16 or 24 characters ( |
Bumping into this too. |
@DanielJoyce can you show an example of how this issue affects you? |
Sure, The issue seems to be using insta with rstest and the test case feature to parametrize the tests. The tests and snapshots would pass on my dev box, but failed in CI as the test case execution order seemed to be swapped. Explicitly naming the tests fixed the issue local dev is using rust 1.71, CI, I don't know the rust verision. Test is something like this #[rstest]
#[case("/path/to/some/file.yml")]
#[case("/path/to/some/file2.yml")]
fn do_something_with_yaml(#[case] file: string) {
/// Set up a file reader to read from the file
....
/// Both of these structs impl Serialize, one is for reading a file, the other is the canonical datastructure
/// used by the library. I just want to snapshot a few things so unintended struct changes cause build failures.
let some_data_structure = serde_yaml::from_reader(file_reader).unwrap();
let some_other_structure = some_data_structure.try_into().unwrap();
/// This would fail in CI, where the snapshot file checked in on dev would be compared with the wrong test
assert_yaml_snapshot!(some_other_structure);
/// This works, explicitly naming the snapshot
assert_yaml_snapshot!(file, some_other_structure);
} I don't think insta quite captures enough data to distinguish these two cases reliably, especially when different rust compiler versions are involved, which can lead to field/function reordering. |
the way rstest expands test cases basically breaks the invariants that insta auto-name relies on. |
This may just need to be a documentation thing. |
This is documented but I guess not well enough. The docs have a snippet for how to make this work best with rstest: https://insta.rs/docs/patterns/ TLDR: macro_rules! set_snapshot_suffix {
($($expr:expr),*) => {
let mut settings = insta::Settings::clone_current();
settings.set_snapshot_suffix(format!($($expr,)*));
let _guard = settings.bind_to_scope();
}
}
#[rstest]
#[case(0, 2)]
#[case(2, 4)]
fn test_it(#[case] a: usize, #[case] b: usize) {
set_snapshot_suffix!("{}-{}", a, b);
insta::assert_debug_snapshot!(a * b);
} |
What happened?
Let this code example:
In this case all files will have the same name. This is due to
_function_name
macro implementation that assume it should be used in only in the#[test]
function.I know that is not a good practice call a function that do the assert but this issue is raised up when somebody tried to integrate
insta
withrstest
la10736/rstest#183What about of using something like
thread::current().name().unwrap().to_string()
to get the current name? that's the onecargo test
use to log the test and so should be always the correct one.Reproduction steps
use insta::assert_yaml_snapshot;
mod test_option_value {
use super::*;
fn assert(v: u32) {
assert_yaml_snapshot!(v);
}
}
The text was updated successfully, but these errors were encountered: