(Not sure if this should be an escargot question...)
I'm writing integration tests for different feature flags.
This is how I'm setting up the test env:
impl TestEnv {
fn new() -> Self {
TestEnv {
cache_dir: TempDir::new(".tldr.test.cache").unwrap(),
config_dir: TempDir::new(".tldr.test.config").unwrap(),
input_dir: TempDir::new(".tldr.test.input").unwrap(),
default_features: true,
features: vec![],
}
}
/// Disable default features.
fn no_default_features(mut self) -> Self {
self.default_features = false;
self
}
/// Add the specified feature.
fn with_feature<S: Into<String>>(mut self, feature: S) -> Self {
self.features.push(feature.into());
self
}
/// Return a new `Command` with env vars set.
fn command(&self) -> Command {
let mut build = escargot::CargoBuild::new()
.bin("tldr")
.current_release()
.current_target();
if !self.default_features {
build = build.arg("--no-default-features");
}
if !self.features.is_empty() {
build = build.arg(&format!("--feature {}", self.features.join(",")));
}
let run = build.run().unwrap();
let mut cmd = run.command();
println!("Command: {:?}", cmd);
cmd.env("TEALDEER_CACHE_DIR", self.cache_dir.path().to_str().unwrap());
cmd.env("TEALDEER_CONFIG_DIR", self.config_dir.path().to_str().unwrap());
cmd
}
}I can then invoke the binary with various feature configs like this:
TestEnv::new().with_feature("logging").command()...
TestEnv::new().with_feature("networking").command()...
TestEnv::new().no_default_features().command()...The problem is that when tests run in parallel, some of them randomly fail. They pass if I run them sequentially.
The way I understand it, escargot runs cargo for the specified target. It's cargo's job to determine whether to rebuild or not.
If the arguments change, then of course cargo will do a rebuild. But since tests run in parallel, it's possible that the "wrong" binary is used while the rebuild is still in process...
Is there a way to use a separate build directory per feature flag configuration? Or maybe you could add some kind of opt-in mutex feature to assert_cmd that enforces assert_cmd based tests to run sequentially?
(Not sure if this should be an escargot question...)
I'm writing integration tests for different feature flags.
This is how I'm setting up the test env:
I can then invoke the binary with various feature configs like this:
The problem is that when tests run in parallel, some of them randomly fail. They pass if I run them sequentially.
The way I understand it, escargot runs cargo for the specified target. It's cargo's job to determine whether to rebuild or not.
If the arguments change, then of course cargo will do a rebuild. But since tests run in parallel, it's possible that the "wrong" binary is used while the rebuild is still in process...
Is there a way to use a separate build directory per feature flag configuration? Or maybe you could add some kind of opt-in mutex feature to
assert_cmdthat enforcesassert_cmdbased tests to run sequentially?