Allow @TestScoped to play nicely with a shared thread pool
Timothy Basanov
I use GuiceBerry to test interceptors for gRPC server.
One of the quirks of an in-process gRPC server is that sometimes it enforces usage of a static internal thread pool. As a result two tests may inadvertently share the same thread pool.
It would be nice to have a GuiceBerry API to allow to set a test id for a current thread.
// T1: on the main test thread t = Thread.currentThread(); // T2: on a thread in a thread pool passing t via some other means TestScope.resetParentThread(t); // now this thread share TestScope with the parent thread
TestScope depends on InheritableThreadState in com.google.guiceberry.GuiceBerryUniverse#currentTestDescriptionThreadLocal as a result once a test used a thread any subsequent test would use test-scoped objects from a previous test.
Sometimes I want to tell GuiceBerry to reset the internal test scope ThreadLocal and set it to a specific test.
The simplest way to do this is to call currentTestDescriptionThreadLocal.get() to get a known good state and pass to currentTestDescriptionThreadLocal.set() when a thread state should be reset.
I have not found a way to do this without reflection.
Resolves: #35
Changes TestScope contract to explicitly propagate to children
threads and to be explicitly closed when test execution is finished.
This prevents several threads from accidentally sharing the same
ThreadScope by reusing a thread pool.
Add an additional API to allow TestScope propagation to non-children
threads and shared thread pools:
InternalState TestScope.getInternalStateForCurrentThread();
void TestScope.setInternalStateForCurrentThread(InternalState);
This allows testing of multi-threaded servers that have
a static internal thread pool shared between tests.