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:
.
├── Cargo.lock
├── Cargo.toml
└── subcrate/
├── Cargo.toml
├── data/
│ ├── a.txt
│ └── b.txt
├── src/
│ └── lib.rs
└── tests/
└── example_test.rs
example_test.rs contents:
extern crate test_generator;
use test_generator::test_resources;
use std::path::Path;
#[test_resources("data/a.txt")]
fn file_exists(resource: &str) {
assert!(Path::new(resource).exists());
}
This results in a compile-time error:
error: custom attribute panicked
--> subcrate/tests/example_test.rs:7:1
|
7 | #[test_resources("data/a.txt")]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= help: message: no resource matching the pattern data/a.txt
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:
test file_exists_subcrate_data_a_txt ... FAILED
failures:
---- file_exists_subcrate_data_a_txt stdout ----
thread 'file_exists_subcrate_data_a_txt' panicked at 'assertion failed: Path::new(resource).exists()', subcrate/tests/example_test.rs:9:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
failures:
file_exists_subcrate_data_a_txt
test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out
For now, a workaround is to manually change the working directory from within the test:
let current_dir = std::env::current_dir().unwrap();
std::env::set_current_dir(current_dir.parent().unwrap()).unwrap();
Edit: it seems this has the wrong effect when run multiple times, the following seems more robust:
let working_dir = Path::new(env!("CARGO_MANIFEST_DIR")).parent().unwrap();
std::env::set_current_dir(working_dir).unwrap();
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.
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.rscontents: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.