Using cargo-nextest to test synchronous blocking APIs

[ColinFinck]

Hello everybody!

I want to test a synchronous API that may either block indefinitely or time out after a known deadline. My idea is to run it in a dedicated thread and have another thread wait until after the deadline. If my first thread testing the API is still running by then, the API has not timed out and is considered blocking.

However, when the API is successfully detected as blocking, I need a way to kill the still-running thread. Rust provides no forceful ways to terminate another thread, and I cannot use any graceful ways given that my API is blocking indefinitely.

I just discovered cargo-nextest and wonder if its process-per-test design can help me here. I can call std::process:exit(0) from any thread to terminate all threads, and this even returns success for my test. Likewise, I can report failure back to cargo-nextest via std::process::exit(1).

Now I have two questions:

1. Is this behavior official and can I rely on it for now and future cargo-nextest releases?

2. Relying on this behavior makes my test specific to cargo-nextest and it won't run on cargo test anymore. Can I detect the presence of cargo-nextest and output an error if my test is run with a different runner?

Is all of this even best practice? Or am I missing a better way to test blocking APIs?

Thank you in advance,

Colin Finck

[sunshowers]

Thanks for the questions!

Is this behavior official and can I rely on it for now and future cargo-nextest releases?

The process-per-test behavior is guaranteed to be the default behavior of nextest now and into the future. See https://nexte.st/docs/design/why-process-per-test for the rationale.

Relying on this behavior makes my test specific to cargo-nextest and it won't run on cargo test anymore. Can I detect the presence of cargo-nextest and output an error if my test is run with a different runner?

You can check for NEXTEST=1 and NEXTEST_EXECUTION_MODE=process-per-test, as documented at https://nexte.st/docs/configuration/env-vars/#environment-variables-nextest-sets.

Is all of this even best practice? Or am I missing a better way to test blocking APIs?

Everything you said is quite reasonable. See the appendix in the first link for discussion about thread termination being hard.

[ColinFinck]

Thank you very much for the prompt and helpful reply! 👍