-
-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
timeout_ms does not cause test to stop #79
Comments
Can this behavior be added to this repo's tests? Perhaps something like this would work: #[test]
#[serial(timeout_ms = 500)]
#[should_panic]
fn timeout_can_panic() {
loop {
thread::sleep(Duration::from_secs(1));
}
} |
Here is another peculiar example of erroneous behavior - a test without a timeout can also get stuck: #[cfg(test)]
mod tests {
use serial_test::serial;
use std::{thread, time::Duration};
#[test]
#[serial]
fn test_a_thing() {}
#[test]
#[serial(timeout_ms = 50)]
fn test_oops_run_forever() {
loop {
thread::sleep(Duration::from_secs(1));
}
}
#[test]
#[serial]
fn test_another_thing() {}
} prints:
I hope that this helps! |
Yeah. So, it's original purpose was trying to catch scenarios where tests had gotten stuck because of things like that (or before I fixed that, weird scenarios with nested test calls). #68 got raised and #71 because originally the timeout was set per all tests, but it was hard to figure out where to set it because of ordering issues. It's meant as a "timeout on the serial lock", not a "how long does this test take to run" timeout, but if the latter did exists, it would be a separate attribute. I'm now leaning towards removing the entire thing given this confusion and I'm not sure how useful it is anymore. @Licenser You raised the previous issues with it. Would you be ok if I removed timeout_ms entirely, or do you still have a use case for it? |
Oooh, I've just seen https://docs.rs/ntest/latest/ntest/attr.timeout.html which may aid the original use case. Should work in combination with |
I think removing it is fine, I never got around to making tests timeout to a per-test basis, sorry. |
No worries. I should probably have spotted/flagged issues with this earlier. Also deleting is generally much easier to do anyways. |
#83 solves this by removing timeout_ms |
That's understandable, and somewhat unfortunate for our use case. A per-test timeout is a useful feature.
Ok, we will find an alternate solution. Thanks! |
When using
timeout_ms
, a long-running test doesn't seem to time out:For example, the test:
will eventually print
test tests::test_oops_run_forever has been running for over 60 seconds
.I would expect an expired timeout to panic and cause the test to fail.
The text was updated successfully, but these errors were encountered: