nunit: Test timeout with teardown executed?
Hi folks, I’ve done a bit of searching and can’t find a solution. Searching timeout in the issues here has some relevant results but issues are either closed without resolution (from years back) or still open.
I have a simple question: for those of us that require a way to have a test timeout but still execute the teardown what are our options? If a test case does some setup, and times out during the test, in many cases the teardown still needs to execute. That is, there is still some clean up that needs to happen so things are healthy for the next test.
I’ve searched and pondered but haven’t found a solution. Can you recommend something? Are there any extensions points maybe? It seems timeout functionality is of limited use if we cannot clean up after the timed out test. Arguably, cleaning up after a timed out test can be more important than even a successful test.
About this issue
- Original URL
- State: open
- Created 7 years ago
- Comments: 30 (26 by maintainers)
Just want to know if anyone implement [TearDown] execution after [Timeout] is reached. Maybe anything changed in NUnit framework that can simplify implementation on this enhancement ? @jnm2 @CharliePoole @ChrisMaddock Thanks,
Sorry guys, I am on vacation with my wife’s family in Portugal, so I haven’t been doing a good job of keeping up with discussions. I also prefer option 2. I think it is most elegant from a code perspective and I also think it gives the user what they would expect without having to read documentation of what the attribute does or does not include. I like it because it is very explicit and would allow you to assign different timeouts to each.
Weirdly I’m not a tie breaker because I am okay with either approach and only have a small preference for option 2. Maybe @rprouse should weigh in, especially since we’re discussing compatibility again. 😀
Sounds like a decision!
One thing we haven’t resolved, however. 😞 What should be the meaning of a
TimeoutAttributeplaced on a fixture or on the assembly. Should it keep it’s current meaning or apply only to the test? Alternatively, should we create aDefaultTimeoutAttributesince that’s what[Timeout]on a fixture actually is.@jnm2 This is one of those examples I was referring to where I used the same attribute with two subtly different meanings. Turns out it almost always gets us into trouble. 🤕
Charlie
Option 2 is a bit of work, but would give cleaner code. If we go that way, I’m willing to give it a shot.
I hate properties that act like feature switches. Can we use a new attribute instead?
I have a strong suspicion that there is a subset (possibly large) of users, who make use of
--timeoutbut notTimeoutAttribute.@jnm2 I didn’t have separate
IncludeSetUpandIncludeTearDownproperties in my list of alternatives. Although they are hypothetically possible, they really don’t fit in the design of nested commands and would require some pretty ugly code. Currently, both the initialization of the timeout and the cancellation take place in the same bit of code, keeping everything nice and symmetrical. I think it’s better to keep it that way rather than letting the two includes vary independently of one another.