TestResourceScope.MATCHING_RESOURCES ignores configuration annotations from QuarkusTestResourceConfigurableLifecycleManager

[yrodiere]

Describe the bug

From what I can see, only the FQCN of the test resource lifecycle manager and the configured scope are taken into account when grouping together tests with matching resources:

quarkus/test-framework/common/src/main/java/io/quarkus/test/common/TestResourceManager.java

Lines 321 to 332 in 2fc4833

	public static Set<TestResourceManager.TestResourceComparisonInfo> testResourceComparisonInfo(Class<?> testClass,
	Path testClassLocation) {
	Set<TestResourceClassEntry> uniqueEntries = getUniqueTestResourceClassEntries(testClass, testClassLocation, null);
	if (uniqueEntries.isEmpty()) {
	return Collections.emptySet();
	}
	Set<TestResourceManager.TestResourceComparisonInfo> result = new HashSet<>(uniqueEntries.size());
	for (TestResourceClassEntry entry : uniqueEntries) {
	result.add(new TestResourceComparisonInfo(entry.testResourceLifecycleManagerClass().getName(), entry.getScope()));
	}
	return result;
	}

This seems incomplete, as test resource lifecycle managers can implement QuarkusTestResourceConfigurableLifecycleManager to be customized per-test, like this:

https://github.com/quarkusio/search.quarkus.io/blob/41e3b9f2de465ea2dc74efaa46ee44b310d5cc08/src/test/java/io/quarkus/search/app/testsupport/QuarkusIOSample.java#L510-L531

https://github.com/yrodiere/search.quarkus.io/blob/42ebd004b6fa5d92960b0615fb8ead6b1b6cb726/src/test/java/io/quarkus/search/app/SearchServiceTest.java#L42

Expected behavior

Tests are considered to have matching resources if they have the same resource lifecycle managers with the same arguments.

Actual behavior

Tests are considered to have matching resources if they have the same resource lifecycle managers, regardless of arguments.

How to Reproduce?

Check out quarkusio/search.quarkus.io#345 , revert the last commit, and see how resources are reused despite the

Or, probably simpler, add a unit test next to the existing ones for @WithTestResource within Quarkus itself.

Output of uname -a or ver

No response

Output of java -version

No response

Quarkus version or git rev

No response

Build tool (ie. output of mvnw --version or gradlew --version)

No response

Additional information

Related conversation: quarkusio/search.quarkus.io#345

PR introducing the feature: #42852

[quarkus-bot]

/cc @radcortez (config)

[geoand]

I will have to check this out as I don't really remember any of the details :)

[geoand]

Tests are considered to have matching resources if they have the same resource lifecycle managers, regardless of arguments.

When you say arguments, I assume you mean the config annotation, right?

[yrodiere]

Tests are considered to have matching resources if they have the same resource lifecycle managers, regardless of arguments.

When you say arguments, I assume you mean the config annotation, right?

Right.

[geoand]

@yrodiere I opened #44215. I am pretty sure it doesn't cover this exact case It should cover this case too

[yrodiere]

So, it's moved to #44279.

I think that PR handles @WithTestResource#initArgs, but not configuration annotations... It takes io.quarkus.test.common.TestResourceManager.TestResourceClassEntry#args into account for comparison, but not io.quarkus.test.common.TestResourceManager.TestResourceClassEntry#configAnnotation.

To be clear when I talk about "configuration annotations" I mean this:

quarkus/test-framework/common/src/main/java/io/quarkus/test/common/TestResourceManager.java

Lines 157 to 160 in ac87489

	if (testResource instanceof QuarkusTestResourceConfigurableLifecycleManager
	&& entry.getConfigAnnotation() != null) {
	((QuarkusTestResourceConfigurableLifecycleManager<Annotation>) testResource)
	.init(entry.getConfigAnnotation());

quarkus/test-framework/common/src/test/java/io/quarkus/test/common/TestResourceManagerTest.java

Lines 216 to 224 in 12fe9e0

	public static class AnnotationBasedQuarkusTestResource
	implements QuarkusTestResourceConfigurableLifecycleManager<WithAnnotationBasedTestResource> {
	private String key;
	@Override
	public void init(WithAnnotationBasedTestResource annotation) {
	this.key = annotation.key();
	}

... which is separate from @WithTestResource#initArgs. It's an alternative to it, I think.

[geoand]

Ah right, I had handled that, but forgot about it...

I'll open a new PR

[geoand]

#44324