Optimize SmartDirtiesSkippedClassListener

[seregamorph]

Maybe enhance JupiterIntegrationTestFilter skipping fast the excluded test which can be eagerly evaluated

[brody-0125]

@seregamorph Would you mind if I took a pass at this follow-up optimization? 😄

My understanding

During multi-class ordering, SmartDirtiesTestsSorter resolves a MergedContextConfiguration for each class classified as a Spring integration test. Under the default condition configuration, Jupiter skips a class annotated with @Disabled as a whole, so we can avoid resolving its Spring configuration.

Possible approach

The implementation approach I have in mind is to make this decision in SmartDirtiesClassOrderer. It can read junit.jupiter.conditions.deactivate through ClassOrdererContext.getConfigurationParameter(...) to account for condition deactivation, and use JUnit's AnnotationSupport.isAnnotated(...) to check for class-level @Disabled.

For the multi-class path, I would add a wrapper around the SPI-selected JupiterIntegrationTestFilter to apply the exclusion predicate. This filter determines whether a class is treated as a Spring integration test for context grouping; the wrapper would delegate to the configured filter for classes that are not eagerly excluded. The singleton path bypasses the sorter, so it needs the same exclusion check.

The fast path would only exclude known-disabled classes from Spring context grouping. Their Jupiter descriptors would remain in the execution plan, and SmartDirtiesSkippedClassListener would continue handling skips discovered at runtime.

Does this direction match what you had in mind? I'm still checking the edge cases.

[seregamorph]

@seregamorph Would you mind if I took a pass at this follow-up optimization? 😄

Sure (go ahead)!

Just few notes
What about other Disabled* annotations like DisabledInNativeImage which is a meta-annotation to @DisabledIfSystemProperty?
What I see is that these are going thru junit extensions like @ExtendWith(XExecutionCondition.class) which may be evaluated via org.junit.jupiter.engine.execution.ConditionEvaluator

At least I'd start my research there

[brody-0125]

@seregamorph Thanks for pointing me toward ConditionEvaluator.

I followed the registration path in ClassBasedTestDescriptor.prepare(). It builds the class's extension registry from the parent registry, registers extensions from annotations and fields, and creates the class's ExtensionContext. Jupiter then passes these to ConditionEvaluator to determine whether the class should run.

I also added some logging and ran a small test to check the sequence. The excerpt below follows the order in which the events occurred. The bracketed labels are my own log markers:

--- Discovery / ordering ---

[ORDER_BEGIN] TracingOrderer -> SmartDirtiesClassOrderer.orderClasses
[SPRING_CONFIG] ActiveB via Bootstrapper.processMergedContextConfiguration
[SPRING_CONFIG] DisabledA via Bootstrapper.processMergedContextConfiguration
...
[DISCOVER_END] Launcher.discover returned TestPlan

--- Execution ---

[PLAN_START] TestExecutionListener.testPlanExecutionStarted
...
[CONDITION_CONSTRUCT] DisabledTraceCondition.<init>
[CONDITION] DisabledA scope=class context=ClassExtensionContext via DisabledTraceCondition.evaluateExecutionCondition
[SKIP] DisabledA via TestExecutionListener.executionSkipped

Here, DisabledA is a test class skipped by a custom ExecutionCondition. Its Spring configuration is processed during class ordering, and Jupiter evaluates the condition later, during execution.

ConditionEvaluator could still be called during ordering, but Jupiter's execution registry and ExtensionContext have not been prepared at that point. It looks like we would need to prepare an evaluation environment ourselves and also verify whether evaluating the relevant conditions before execution produces consistent results.

I'll check the overhead of preparing and using an evaluation context in SmartDirtiesClassOrderer, as well as whether the results stay consistent with Jupiter's own evaluation during execution.