-
Notifications
You must be signed in to change notification settings - Fork 15
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
Add support for Cargo workspaces #6
Comments
I also just ran into this problem. Just to add some context here:
Searching crates.io for With #[test_generator::test_resources("res/*/input.txt")]
fn for_each_file(path: &str) {
assert!(std::path::Path::new(path).exists());
} With use std::path::PathBuf;
#[rstest::rstest]
fn for_each_file(#[files("res/*/input.txt")] path: PathBuf) {
assert!(path.exists())
} |
(small addendum): I think the modern approach is to just write your own test harness with something like libtest-mimic. This way you don't need any proc macros. |
Currently, it appears that support for Cargo workspaces is limited, due to the way resource files are discovered via relative paths. This is easiest to show with an example:
example_test.rs
contents:This results in a compile-time error:
Okay, so it expects a path from the workspace root. Changing the path to
#[test_resources("subcrate/data/a.txt")]
compiles fine, but now the test fails:For now, a workaround is to manually change the working directory from within the test:
Edit: it seems this has the wrong effect when run multiple times, the following seems more robust:
after which the test passes. However, I think this behavior is not self-consistent.
I would suggest either the search path begins from the local crate root rather than the workspace, or the working directory is changed within the test body in the generated code. I suppose this would be a breaking change, unfortunately.
The text was updated successfully, but these errors were encountered: