invert dependencies of client TCK

[t1]

The smallrye-graphql-client-tck has runtime dependencies on smallrye-graphql-client and smallrye-graphql-client-implementation-jaxrs, i.e. the implementation. To run the TCK one has to start it directly.

To become a real TCK suitable for a spec, this has to be the other way around. The implementation must depend on and run the TCK. According to this comment, we need to update to JUnit 5.8.0 and define a Test Suite.

[jmartisk]

I assume you mean we basically need to split the TCK module into two modules

• One (let's call it "core") with the actual tests, that can be moved over into the spec as is
• One "runner" module which depends on the "core", adds the runtime dependencies, but has no actual tests, and is configured to run the tests from core?

Is this understanding correct?

[t1]

No. The current client tck maven module has a dependency on the implementation (and actually the implementation-jaxrs). If there were other implementations, this would not work. Instead, all implementations need to have a dependency on the tck to run the tests against their implementation. The other specs use testng, but there was a recent addition to JUnit 5.8.0-M1 that allows to define test suites that can be used for this.

I'm on it.

[jmartisk]

Ah, that you mean.
I am generally not a fan of including a TCK dependency right into an implementation module - even though it has the test scope, it still can mess up the module's dependency tree quite a bit (and it's unpredictable because you generally don't directly control the dependencies of the TCK). So maybe I'd say that each of the implementation modules (vertx, jaxrs) should have its own module dedicated to running the tck. It means more modules, but more maintainable structure.
But that's just my opinion

[t1]

Okay, maybe that's another option. But this would still be a prerequisite, wouldn't it?

[jmartisk]

Either you move the dependency from the tck module to implementation-* modules (your original suggestion), or you remove it from the tck module and add the new "runner" modules (perhaps named client/tck-runner-jaxrs and client/tck-runner-vertx or so), which I think is better. We will have to choose one or the other.
I guess @phillip-kruger should decide :)

[t1]

The difficult part is to allow implementations or tck-runners to run the tck. This is done here. A second step might introduce the runners. This is trivial, as you only have to move the dependency and the DynamicTckSuite/TypesafeTckSuite. I suggest we merge this now, and if anybody thinks that having separate runners is necessary, that's a second PR. What do you think?