Closed thomhurst closed 2 months ago
It seems like the responsibility of the test framework.
I just thought since there's a cancellation token passed to us in the request context, that'd be a good place to cancel it.
But no worries, it should be easy enough to implement in my framework.
Feel free to close :)
Reading again the ticket, I am thinking that maybe I didn't get what you were suggesting. Is your timeout a time per test or a global test execution timeout?
Sorry if it wasn't clear. A global timeout for the whole test session
Ok in that case I think it makes sense :) I was thinking about the platform handling a test method timeout and I was thinking that while technically we could do something along this line it seemed like something a lot easier to handle at framework level.
@MarcoRossignoli this seems like a useful request, WDYT?
Let's go with --timeout <val>
where <val>
will be either an int corresponding to timout in seconds or a string in the format <value>[h|m|s]
I've seen in many test suites something go wrong before where something is hanging and the test suite just becomes stuck.
Adding a timeout option, that if exceeded, will send a cancellation signal to the framework's cancellation token could help give developers faster feedback and also save them money if they're using less compute time on their build agents.
The format could be a C# stringified timespan or you could come up with your own format.
Example:
dotnet run --timeout 00:10:00
AB#2200943