Enable ability to not print out stack trace upon timeout expiration

[GregHilston]

I found myself in a situation where a given test's timeout expiring was a good thing. This library allowed me to write my unit test just fine but I was unable to hide the stack trace in this successful situation.

I dug through the code and attempted to set the global variable SUPPRESS_TIMEOUT to True which would cause early returns before the stack trace dumps but that did not end up working for me.

[flub]

I'm not sure I understand your requirement. It would be pretty unhelpful to fail a test and not print out any reason why it failed.

On Wed 19 Aug 2020 at 19:02 -0700, Greg Hilston wrote:

I found myself in a situation where a given test's timeout expiring was a good thing. This library allowed me to write my unit test just fine but I was unable to hide the stack trace in this successful situation.

I dug through the code and attempted to set the global variable SUPPRESS_TIMEOUT to True which would cause early returns before the stack trace dumps but that did not end up working for me.

[GregHilston]

I think there's some miscommunication here. In my situation, the timeout expiring is the desired affect and therefore the test is passing.

So I'd wish to not print out the stack trace. Does that clarify a bit more?

[flub]

Would you mind describing your situation a bit more? If the timeout triggers that means either the sigalrm or the os._exit() method will be used to terminate some existing execution. This is generally not good.

Is this perhaps something that you want to mark xfail instead?

Also, generally pytest-timeout's design really considers it much better to let something just run until completion. This is a last resort. E.g. can you just time the execution and let it run until completed? Than when it finishes you call pytest.fail() if it took less than your desired time.

On Sun 23 Aug 2020 at 13:14 -0700, Greg Hilston wrote:

I think there's some miscommunication here. In my situation, the timeout expiring is the desired affect and therefore the test is passing.

So I'd wish to not print out the stack trace. Does that clarify a bit more?

[GregHilston]

Sure thing! So right now I'm writing a small framework that leverages a while True block to continuously listen to a blocking web socket.

Therefore, in my use case, my code should never finish. While I could modify my code to call a should_continue function, instead I was leveraging pytest-timeout to prove that my code was still running for at least n seconds.

I know this isn't a typical situation but figured I could unit test it.

[flub]

I can strongly recommend to write the loop so you can terminate it instead. Personally I like wrapping these kind of things into iterators that can be consumed in a for loop but there are other reasonable options.

I also wonder about what you are actually testing with this. For all you know your code could be deadlocked when it times out. You rather care more about that you can receive and process things from the socket.

If you really, really want to write a slow test - and in this case I hope you're not forcing everyone to run a slow test suite - I think you're best off just writing the SIGALRM code in the test directly otherwise your test would break if someone used a different commandline flag.

On Wed 26 Aug 2020 at 18:09 -0700, Greg Hilston wrote:

Sure thing! So right now I'm writing a small framework that leverages a while True block to continuously listen to a blocking web socket.

Therefore, in my use case, my code should never finish. While I could modify my code to call a should_continue function, instead I was leveraging pytest-timeout to prove that my code was still running for at least n seconds.

I know this isn't a typical situation but figured I could unit test it.