KafkaCluster subclass constraint

[tombentley]

The junit5 extension supports fields and parameters of type KafkaCluster. It also supports declarations with a type that's a subclass of KafkaCluster. The subclass is treated as just another constraint that a provider needs to support. For example:

@Test public void myTest(InVmKafkaCluster cluster) {
    // ...
}

That's fine for tests which need to use some particular provider (e.g. maybe InVmKafkaCluster exposes some extra method that your test needs to use). But because this is a constraint that's not expressed as an annotation it means you can use that with the @TemplateTest support. For example you can't write a @TemplateTest that tests over some particular set of providers.

The simplest way of doing that would be to support an annotation (let's call it @InstanceOf, just for concreteness in this issue, but the name is up for grabs) that added the subtype constraint without needing the parameter or field declaration to actually be that subtype. For example:

@Test public void myTest(@InstanceOf(InVmKafkaCluster.class) KafkaCluster cluster) {
    // ...
}

There's no difference here for @Test-annotated tests, but for @TemplateTests it would let you write something like this:

public static Stream<InstanceOf> providers() {
    return Stream.of(ConstraintUtils.instanceOf(InVmKafkaCluster.class),
        ConstraintUtils.instanceOf(ContainerBasedKafkaCluster.class),
        ConstraintUtils.instanceOf(StrimziKafkaCluster.class)
    );
}

@TestTemplate
public void myTest(@DimensionMethodSource("providers") KafkaCluster cluster) {
    // ...
}

This becomes still more useful if we provided a way of adding extra constraints externally from the test source code (e.g. via a json file, for example). That would mean that by default when testing locally you'd use the fastest provider (typically in-VM), but on your CI server you'd add the extra constraint which would force the CI run to use your KaaS instead. Your test code would be the same. You inner loop would be optimized when testing locally. Your CI would guarantee that your code was tested with the real infra your application would be running on. Note this "externalised extra constraints" is really a separate issue that's orthogonal to this one.