Support passing parameters to a QuarkusTestResource

[geoand]

Resolves: #9066

[geoand]

This nees to be to ensure that we don't have conflicting args.

Done

[gsmet]

Interesting! I added a comment and a question.

[famod]

What happens if you have:

• Test 1 with @QuarkusTestResource(value=MyMgr.class, initArgs={"foo=true"})
• Test 2 with @QuarkusTestResource(value=MyMgr.class, initArgs={"foo=false"})

or something like that?

[geoand]

The PR makes sure that the test fails

[knutwannheden]

The PR makes sure that the test fails

Would an alternative be to instantiate MyMgr twice (and call one with init("foo=true") and the other with init("foo=false"))?

[geoand]

The PR makes sure that the test fails

Would an alternative be to instantiate MyMgr twice (and call one with init("foo=true") and the other with init("foo=false"))?

I think that could lead to surpising results. Best keep with the established Quarkus practice.

[knutwannheden]

I think that could lead to surpising results. Best keep with the established Quarkus practice.

I see. One would have to create some "dummy" classes in these (hopefully rare) situations. I was for instance thinking of the situation where I need two datasources. Then I would have liked to declare two annotations like @QuarkusTestResource(PostgresDatabase.class) (default datasource) and @QuarkusTestResource(PostgresDatabase.class, initArgs="datasource=other"). Possibly there could be some flag in the future to allow this kind of usage.

[gsmet]

I think that could lead to surpising results. Best keep with the established Quarkus practice.

It might be just me but I think I would:

• allow two resources with different initArgs
• disallow having two resources with the exact same initArgs

This way, we have the best of both world: flexibilty and keeping the behavior as is if you don't use initArgs.

WDYT?

[knutwannheden]

@gsmet What you propose would also be my preferred solution.

[geoand]

I don't know... I am not convinced about having different initArgs. I think it would lead to users to believe that they can use different @QuarkusTestResource on different classes and that those would be applied per test.

[famod]

By the way, what's the status of having individual resources per test class? Anything planned?

The way the annotation can be used and how it is documented (JavaDoc) leaves the impression you can have individual resources per test class.

[geoand]

By the way, what's the status of having individual resources per test class? Anything planned?

Nothing done so far, but hopefully soon :)

The way the annotation can be used and how it is documented (JavaDoc) leaves the impression you can have individual resources per test class.

Would you like to propose a way for it to be written differently that would cause less confusion?

As I mentioned before, I think that the if we allow @QuarkusTestResource with different initArgs, it will only add to the confusion.

[geoand]

So the question becomes, what should we do about this?

[stuartwdouglas]

I think that different args makes sense, e.g. starting two different databases of the same type is definitely a common use case, however I can see how it could be confusing.

Maybe make this annotation @repeatable, IMHO this would make it clearer that it can be used to create multiple resources.

[geoand]

@QuarkusTestResource is already repeatable, so I just lifted the restriction I had imposed on not allowing different initArgs.
I also added a note to the javadoc of @QuarkusTestResource to make clarify how it's used.

[geoand]

CI failure has nothing to do with this PR:

2020-05-11T07:49:51.8096777Z Caused by: java.io.IOException: Could not start process: <EOF>
2020-05-11T07:49:51.8096946Z 	at de.flapdoodle.embed.mongo.AbstractMongoProcess.onAfterProcessStart(AbstractMongoProcess.java:79)
2020-05-11T07:49:51.8097071Z 	at de.flapdoodle.embed.process.runtime.AbstractProcess.<init>(AbstractProcess.java:116)

[geoand]

@stuartwdouglas, @gsmet WDYT now?

Comments addressed