@TestFactory methods should evaluate ContainerExecutionCondition extensions instead of TestExecutionCondition extensions

[marcphilipp]

Currently, @TestFactory nodes provide a TestExtensionContext and evaluate TestExecutionConditions. Since they are containers they should rather provide a ContainerExtensionContext and evaluate ContainerExecutionConditions.

Implementation Note

After changing this, JupiterTestDescriptor can implement shouldBeSkipped like this:

@Override
public final SkipResult shouldBeSkipped(JupiterEngineExecutionContext context) throws Exception {
   return isContainer() ? shouldContainerBeSkipped(context) : shouldTestBeSkipped(context);
}

[sbrannen]

Good catch! 👍

[sbrannen]

The problem with making such a change is that extensions for @TestFactory methods would no longer have access to the test instance (which is currently only available via the TestExtensionContext API), even though there is in fact an instance.

Consequently, such extensions would no longer have access to instance state (i.e., fields that may have been initialized or injected).

In other words, such a change would reduce the scope of what such extensions can do.

@junit-team/junit-lambda, let's discuss the pros and cons.

[marcphilipp]

If we merged ContainerExtensionContext and TestExtensionContext (which we will probably have to do for #455 and #48 anyway), this would no longer be a problem. Since #455 is already in progress, I'm setting this issue to blocked.

[marcphilipp]

This issue has become obsolete since [Container|Test]ExtensionContext have been merged into ExtensionContext in #901.