Add TCK tests for MicroProfile Concurrency

[njr-11]

Unless someone else knows of a better way to track this, I'm intending for this issue to be a place to document and collaborate on a list of test scenarios for the MicroProfile Concurrency TCK.

The following will be a checklist of scenarios. There are only a couple to start with, which seemed like some basic things we will need to start making progress. Sign up for a scenario to the TCK by mentioning the git pull number under which you are adding it. When the pull is merged, check the box next to it to indicate it is done,

• create some fake thread context types for TCK tests #61 verify that the MP Concurrency impl provides a builder for ThreadContext
• Issue 60: verify ThreadContext.Builder: cleared, propagated, unchanged methods. #68 verify ThreadContext.Builder API methods: cleared, propagated, unchanged
• Add TCK testing of ThreadContext for reusing Builder.build() #103 verify ThreadContext builder is reusable
• Issue 60: verify currentContextExecutor runs with context #69 verify ThreadContext API method: currentContextExecutor - runnables run with context
• TCK tests for contextual proxies #62 verify ThreadContext API method: contextualCallable - callable runs with context
• TCK tests for contextual proxies #62 verify ThreadContext API method: contextualConsumer - consumer runs with context
• TCK tests for contextual proxies #62 verify ThreadContext API method: contextualFunction - function runs with context
• TCK tests for contextual proxies #62 verify ThreadContext API method: contextualRunnable - runnable runs with context
• TCK tests for contextual proxies #62 verify ThreadContext API method: contextualSupplier - supplier runs with context
• TCK tests for ThreadContext.withContextCapture #88, withContextCapture must reject Async methods without executor because it is not backed by an executor #108, TCK test for withContextCapture switching context #123 verify ThreadContext API method: withContextCapture - dependent actions run with context
• Add TCK testing of ThreadContext for implied clearing of contexts. #97 verify ThreadContext clears context types that are not configured under any category (per JavaDoc requirement)
• TCK test for clearing transaction context #104, TCK test for propagation of Application context #112, Tests for CDI context propagation #126 verify ThreadContext constants are defined and usable: TRANSACTION, SECURITY, CDI, ALL_REMAINING, and APPLICATION, to the extent that it is reasonable to do so when running the TCK. Specifically, security context is left to the implementations to cover in their own testing due to the fact that it would introduce a dependency on servlets (HttpServletRequest.getUserPrincipal) or other vendor-specific technology that is not guaranteed to be available when running the TCK.
• create some fake thread context types for TCK tests #61 verify that the MP Concurrency impl supports configuration and usage of third-party thread context provides supplied via the ServiceLoader
• TCK tests for cdi injection of ThreadContext #114 The container creates a ThreadContext instance per unqualified ThreadContext injection point
• TCK tests for cdi injection of ThreadContext #114 A ThreadContext instance that is injected by the container can be configured via @ThreadContextConfig
• TCK tests for cdi injection of ThreadContext #114 If the @NamedInstance qualifier is present on a ThreadContext injection point that is annotated with @ThreadContextConfig, the container creates a ThreadContext instance that is qualified by the name value
• TCK tests for cdi injection of ThreadContext #114 Application can provide producers of ThreadContext that are qualified by @NamedInstance
• TCK tests for ThreadContext override via MicroProfile Config #95 MicroProfile Config override of ThreadContext that container produces for injection into a field
• TCK tests for ThreadContext override via MicroProfile Config #95 MicroProfile Config override of ThreadContext that container produces for injection into a parameter
• TCK tests for precontextualized tasks #117 verify that when you supply an already-contextualized action/task to a ManagedExecutor's runAsync or supplyAsync method, the action/task runs with the context that was originally captured for it by the ThreadContext contextualRunnable/contextualSupplier method, rather than re-capturing context per the ManagedExecutor's configuration.
• TCK tests for precontextualized tasks #117 verify that when you supply an already-contextualized action/task to a completion stage method that creates a dependent stage (such as thenApplyAsync) the action/task runs with the context that was originally captured for it by the ThreadContext contextual* method, rather than re-capturing context per the ManagedExecutor's configuration.
• create ManagedExecutorTest for TCK and write tests for newIncompleteFuture, runAsync, and supplyAsync #63 verify that the MP Concurrency impl provides a builder for ManagedExecutor
• Issue 60: Verify ManagedExecutor.Builder cleared(), and propagated(). #70 verify ManagedExecutor.Builder API methods: cleared, propagated, maxAsync, maxQueued
• Add TCK testing of ManagedExecutor for reusing Builder.build() #102 verify ManagedExecutor builder is reusable
• TCK tests for maxAsync and maxQueued #67 verify boundaries for ManagedExecutor.Builder maxAsync: positive value is enforced; -1 is allowed; negative and 0 throw an IllegalArgumentException
• TCK tests for maxAsync and maxQueued #67 verify boundaries for ManagedExecutor.Builder maxQueued: positive value is enforced; -1 is allowed; negative and 0 throw an IllegalArgumentException
• TCK coverage for completedStage, completedFuture, failedStage, and failedFuture method of ManagedExecutor #65 verify ManagedExecutor API method: completedFuture - dependent actions run with context
• TCK coverage for completedStage, completedFuture, failedStage, and failedFuture method of ManagedExecutor #65 verify ManagedExecutor API method: completedStage - dependent actions run with context
• TCK coverage for completedStage, completedFuture, failedStage, and failedFuture method of ManagedExecutor #65 verify ManagedExecutor API method: failedFuture - dependent actions run with context
• TCK coverage for completedStage, completedFuture, failedStage, and failedFuture method of ManagedExecutor #65 verify ManagedExecutor API method: failedStage - dependent actions run with context
• create ManagedExecutorTest for TCK and write tests for newIncompleteFuture, runAsync, and supplyAsync #63 verify ManagedExecutor API method: newIncompleteFuture - dependent actions run with context
• create ManagedExecutorTest for TCK and write tests for newIncompleteFuture, runAsync, and supplyAsync #63 verify ManagedExecutor API method: runAsync - action runs with context
• create ManagedExecutorTest for TCK and write tests for newIncompleteFuture, runAsync, and supplyAsync #63 verify ManagedExecutor API method: supplyAsync - action runs with context
• TCK tests for submit and execute #84 verify ManagedExecutor API method: execute - Runnable runs with context
• TCK tests for submit and execute #84 verify ManagedExecutor API method: submit - Runnable/Callable run with context
• TCK tests for ManagedExecutor.invokeAll and invokeAny #73 verify ManagedExecutor API method: invokeAll - Callables run with context
• TCK tests for ManagedExecutor.invokeAll and invokeAny #73 verify ManagedExecutor API method: invokeAny - Callable(s) run with context
• TCK tests for ManagedExecutor shutdown #71 verify ManagedExecutor API method: shutdown - additional tasks cannot be submitted
• TCK tests for ManagedExecutor shutdown #71 verify ManagedExecutor API method: shutdownNow - additional tasks are not submitted, queued/running tasks are canceled
• Add TCK testing of ManagedExecutor for implied clearing of contexts. #100 verify ManagedExecutor clears context types that are not configured under any category (per JavaDoc requirement)
• Add tests for CDI injection of ManagedExecutor #89 The container creates a ManagedExecutor instance per unqualified ManagedExecutor injection point
• Add tests for CDI injection of ManagedExecutor #89 A ManagedExecutor instance that is injected by the container can be configured via @ManagedExecutorConfig
• Add tests for CDI injection of ManagedExecutor #89 If the @NamedInstance qualifier is present on a ManagedExecutor injection point that is annotated with @ManagedExecutorConfig, the container creates a ManagedExecutor instance that is qualified by the name value
• Add tests for CDI injection of ManagedExecutor #89 Application can provide producers of ManagedExecutor that are qualified by @NamedInstance
• Add tests for CDI injection of ManagedExecutor #89 Application can shut down a ManagedExecutor instance that is created and injected by the container
• Create first MPConfig tests for TCK #93 MicroProfile Config override of ManagedExecutor that container produces for injection into a field
• TCK tests for MPConfig overrides of ManagedExecutor injected into method parameter #94 MicroProfile Config override of ManagedExecutor that container produces for injection into a parameter
• Add TCK testing of custom ConcurrencyManager instances. #105 obtain ConcurrencyManager builder, if supported by the concurrency provider, and build & register a custom instance for a class loader. Obtain the instance via getConcurrencyManager(classloader), then release it.
• Tests for CDI context propagation #126 CDI context propagation for ManagedExecutors
• Tests for CDI context propagation #126 CDI context propagation for ThreadContext
• Tests for transaction propagation to dependent stages #130 Tests for transaction propagation to dependent stages

As discussed on the prior MicroProfile Concurrency call (2019-2-21), the above represents the full set of desired TCK scenarios sufficient for the initial release candidate.

[nmittles]

Suggestions for basic TCK scenarios of ManagedExecutor, ThreadContext and their builders:

• verify ManagedExecutor.Builder().maxAsync(X).build() boundaries; 1, -1, and maxInt is successful for X; 0 and -2 throw an IllegalArgumentException for X
• verify ManagedExecutor.Builder().maxQueued(X).build() boundaries; 1, -1, and maxInt is successful for X; 0 and -2 throw an IllegalArgumentException for X
• verify ManagedExecutor.Builder() API methods: build(), propagated(), cleared(), maxAsync(), maxQueued()
• verify ManagedExecutor API methods: builder(), completedFuture(), completedStage(), failedFuture(), failedStage(), newIncompleteFuture(), runAsync(), supplyAsync()
• verify ThreadContext.Builder() API methods: build(), cleared(), propagated(), unchanged()
• verify ThreadContext API methods: currentContextExecutor(), contextualCallable(), contextualConsumer(), contextualFunction(), contextualRunnable(), contextualSupplier(), and withContextCapture()
• verify ThreadContext constants are defined: TRANSACTION, SECURITY, CDI, ALL_REMAINING, and APPLICATION

[njr-11]

@nmittles Thanks for coming up with those scenarios. I believe I've added all of the ones you proposed to the list now, splitting up a few of them up into separate scenarios where too much was included in a single scenario