Incompatibility with rstest's once about nextest

[la10736]

I guess that use one process per test makes useless #[once] attribute. I think that there are scenario where instantiate some resource shared across tests (like docker instances or populate db) only once is really useful... in this case the model one process one test don't works very well.

Is a chance introduce an option to run tests in the same executable with multiple thread that can share resources? I know why you adopt this model and all benefits that this model have, but this kinds of scenario are really common in integration tests.

[sunshowers]

Thanks for the report and the debugging! Yes, one process per test is incompatible with that kind of initialization. The options are:

• Initialize separate, isolated universes for each test, which can work with files on disk and some database situations, but is definitely harder to do with Docker by my understanding.
• Combine all the individual tests into a single #[test] so that it's all run together.

#27 tracks adding the option to add a mode where all tests are run within the same process. It is quite nontrivial, however -- one of the challenges is that individual test data isn't exposed by stable Rust. Regardless, I would be happy to welcome a pull request that does something reasonable in that case.

I think I'm going to close this as a duplicate of #27, since solving that should address this.

[jacg]

Separate, isolated universes for each test, would indeed be useful for avoiding collisions (and in the case of files colliding, this can and should be addressed with some unique filename-generation utility), but #[once]-like features are mostly useful for sharing resources between tests, either because setting up the resource is expensive, or because the tests are somehow coupled by the resource.

Combining tests into an individual test would be a possibility in the latter cases, but then you lose the benefits of fine granularity of failure reporting that comes with small, separate tests. Especially annoying would be the loss of parametrized tests (such as rstest's cases, where different data are injected into the same test).

But these are second-order details. I appreciate that it's difficult, and that solving #27 should address this, so I agree with closing.

Thanks again for the excellent crate!