#5 Detached Access to callback-parameterization

[Henrik Kaipe]

"Detached" shall here be thought of as detached from the test-class.

Right now all access to callback-parameterization must originate from the test-class, where it is accomplished by @ParameterizedCallback-annotated fields or by having @Before, @After and @Test methods have interface parameters.

Support for detached access would allow reusable test utilities to use callback-parameterization through callback-interfaces that the test-class is completely unaware of. Until now all such access must be initiated in the test-class and then passed on to the utility:

@RunWith(CallbackParamsRunner.class)
public TestUsingAnUtility {

@Rule
public AnUtilityTestRule aUtility = new AnUtilityTestRule();

@Before
public void initiateUtility(UtilityCallback callback4Utility) {
aUtility.initWithCallback(callback4Utility);
}

@Test
public void runTheTest() {/*Put test-code here*/}
}

Above the test-rule "AnUtilityTestRule" relies on callback-interface "UtilityCallback" but cannot reach it by itself. Instead the test-class needs to initiate the test-rule by passing the callback-parameterization access to the init-method "initWithCallback(...)", which takes place in the @Before-method "initiateUtility(...)".
So what if the class AnUtilityTestRule would have been able to initiate its "UtilityCallback" on its own? Then its API could be greatly simplified! Its internal concerns could be hidden from the test-class (e.g. UtilityCallback could be a private interface) so that the test-class would drop its before-method and all other knowledge about the interface "UtilityCallback".

But today it is not possible for the AnUtilityTestRule to initiate its UtilityCallback on its own so there is a need for additional CallbackParams features to accomplish this.

This feature-request proposes a solution where AnUtilityTestRule can initiate its own UtilityCallback like this:

UtilityCallback callback = new DetachedParameterizedCallback<UtilityCallback>(){}.accessProxy();

The initiated UtilityCallback-instance would work much like "callback4Utility" in the above test-class - but with one significant difference: Every TestUsingAnUtility-instance would be initiated with its own "callback4Utility", which always work on the same callback-record, whereas ~the detached access-proxy~ would work on the callback-record of the latest TestUsingAnUtility-instance! This means that AnUtilityTestRule only needs to create its callback once and it will be automagically proxied to the callback-record of the currently running test - making it possible to store the callback in a static constant (final) field. If one of the callback-methods is invoked when there is no running test (i.e. there is no callback-record) then an IllegalStateException will be thrown.