Recent changes to feature-requests

Detached Access to callback-parameterization

2012-10-07T08:44:07Z

"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.

API for callback-method return values

2010-12-04T14:42:51Z

Today all callback-invocations will return default-values (i.e. false, 0, null etc depending on return-type), in case they are non-void. Therewith the callback-method return-values constitute an unused piece of API that should be taken care of so. The question is how? Does anyone have any good ideas on what an API for callback-method return-values should look like?
This can be seen as an opportunity to develop some really useful and innovative features, so let us not settle for anything less than really fency features, which benefits cannot be easily reproduced with any existing tools out there. :-)

Support for multiplicity strategies

2010-12-02T22:59:54Z

As of now the constants retrieved from a nested class - usually an enum - will be fed to the combine-strategy in a manner that expects the combine-strategy to include one constant from each enum in each callback-record. This ~API~ seems to fit most situations very well but there should perhaps be ways to instruct the combine-strategy to populate the callback-records with a certain number of constants from a certain enum. Such as having some of the produced callback-records contain two or three of the enum's constants while some other callback-records contain no constant of the particular enum.

I think it would be unwise to be too hasty about this. We should not have a rash API included in the distribution and then later find out there are smarter or more elegant ways to accomplish the same thing. Let's instead have this feature-request link to similar ones and make a more informed decision based on actual needs and a wide collection of different API suggestions.

Support for parallel execution of tests

2010-12-02T22:23:43Z

As of now the testruns that are produced by a CallbackParams test-class are run one at a time. It would be nice if it was possible to execute testruns in parallel, however, and with the current trends toward multi-core CPUs it could allow the test-suite to complete much faster.

Since CallbackParams already creates a separate class-loader for the testruns it would probably not be too hard to make each test-thread run its allotted testruns on its own exclusive class-loader in order to achieve a pretty good thread-safety with little effort for the test-developer.

Improve the API for default interface implementations

2010-11-29T22:25:46Z

The purpose of this API is right now described at "http://callbackparams.org/guide.html#defaults"

The current API itself is not worth describing, however. An idea for a better API is to have the callback-interface specify an inner class that implements CallbackFactory and have that factory produce an instance of the callback-interface at hand; or indicate there will not be any default available by producing null or an instance of anything that does not implement the callback-interface at hand.

The above CallbackFactory-instance would perhaps receive information on the callback-record element at hand as well as the callback-reference (e.g. the callback-method argument or callback-field) through a thread-local static API.