Closed dcz-purism closed 3 years ago
Actually, this only works around the actual problem. While we document that -- --test-threads=1
should be passed to cargo test
, that is not a good thing to expect people to do. People with some Rust background will run cargo test
and get disappointed by the failure.
Can't the test be made to be independent (as they should be)?
If it's too hard to fix the actual problem, we should at least use a better workaround.
Just FYI, I was about to cargo publish
before I ran into this myself. :)
I don't think Cargo offers anything that actually addresses the problem. It seems to be geared towards unit tests, not end-to-end tests. I'm seeing the mutex workaround, and the serial_test crate workaround, but there's nothing about Cargo that guarantees different tests using the same address space.
Perhaps removing those tests from being run using cargo test
and putting them inside a shell script is the non-workaround solution you're looking for?
I don't think Cargo offers anything that actually addresses the problem.
Didn't think it does.
serial_test crate workaround,
Yeah, that's something I thought we might want to try.
Perhaps removing those tests from being run using
cargo test
and putting them inside a shell script is the non-workaround solution you're looking for?
There is no reason for all the tests to be independent tests. You can remove #[test]
attribute from the functions and then just call them sequentially from a test function. I've pushed this solution to master branch now.
Travis tries to parallelize tests by default, whereas end-to-end tests use shared resources, and can't be parallelized.
Inspired by https://docs.travis-ci.com/user/languages/rust/#default-build-script
This hasn't been tested in any way, I'm not sure how to link this commit to Travis.