[Pitch] Test cancellation

[grynspan (Jonathan Grynspan)]

@smontgomery

Many parameterized tests begin as non-parameterized test functions and are later transformed by adding arguments. "Promoting" a test to become parameterized is a pretty common workflow.

We've repeated this claim quite a bit off-forum but we don't actually know it's true, we're just assuming it is. Do we have any statistics backing it up?

@smontgomery

Alternative? To me, only offering one method (such as Test.cancel(), but there could be other spellings) and having it do the "narrowest" cancellation at whichever scope it's called in, makes the most sense.

I would consider it a misdesign for us to "camp" on Test.cancel() now and have it only cancel the current test case. How then do we indicate that the entire test should be cancelled. Or, put another way: "I called Test.cancel() but my test kept running. What gives?"

@smontgomery

This design would also remove the need for this edge case noted in the documentation of Test.Case.cancel():

No it wouldn't. This issue would still exist and Test.cancel() will also behave this way on a detached task. The same callout is present on the documentation for Test.cancel().

@smontgomery

I don't find that very worrisome because it's a static method. But if enough reviewers think that's a concern, then I think we should still have just one method but place it elsewhere; perhaps a global function or within some entirely new type.

I don't think I can do much with this feedback unless you'd like to propose some alternative name (or names) for the function. Did you have something specific in mind?