Allow forward of `cargo test` arguments

[xd009642]

So for my project I have to run with cargo test -- --test-threads 1 as the project uses unix APIs that aren't thread-safe within a process so running the integration tests in parallel causes failures. This means my unmutated run fails and I can't try cargo-mutants on my project. Not sure if there's a way to pass this that I've missed, but if there's not it feels like a useful thing to add (and I'd be willing to help 😄 )

[sourcefrog]

There's not an option for that yet, though I plan to soon add a way to pass options to cargo test: see also #14.

I thought probably

cargo mutants -- -- --test-threads 1

Though, also: I wonder if there's a way for you to make this work safely in your tree without requiring that argument, so that people don't need to remember to add it? I guess you could take a mutex from each test, though that might get annoying...

Anyhow, it's a very reasonable option to add here.

[xd009642]

my tests take a long time to run and the CI and I think the dev guide mentions it as well. I did consider the mutex when I implemented but I felt that it just made it more annoying to write tests .

👍 for the cargo test argument passing implementation. -- -- --test-threads 1 looks a bit odd, but it's intuitive to what it does

[sourcefrog]

I've never used it but https://crates.io/crates/rusty-fork might help?

Rusty-fork provides a way to "fork" unit tests into separate processes.

There are a number of reasons to want to run some tests in isolated processes:

When tests share a process, if any test causes the process to abort, segfault, overflow the stack, etc., the entire test runner process dies. If the test is in a subprocess, only the subprocess dies and the test runner simply fails the test.

Isolating a test to a subprocess makes it possible to add a timeout to the test and forcibly terminate it and produce a normal test failure.

Tests which need to interact with some inherently global property, such as the current working directory, can do so without interfering with other tests.

[xd009642]

Maybe, but possibly not, it's a tool using ptrace so I'd need to check ptraces behaviour inside forks. Also it invokes cargo so not sure how people will feel about nproc number of cargo build processes being launched continuously as it goes through all the tests 😅. I'll add it to my backlog to check out though