Tech stack and operational aspects for the test suite about graphql-over-http HOT 9 CLOSED

Is this issue still relevant?

Somewhat. Perhaps it does not need to stand on its own, as by itself it is not really actionable, but it would be relevant when beginning work on an implementation of a test suite.

How about this: we leave this and other issues labeled with "audits" open until the next working group and decide on a plan for the test suite then. In terms of organisation, perhaps a working test suite could be a milestone?

from graphql-over-http.

We talked about this a bit at the working group meeting today. One of things we explored was the ability to run the test suite in the browser. This would allow us to provide a service where people could enter a URL and then receive results in their browser. They wouldn't have to download or set up anything and they could point it to private URLs that only they had access to.

We also talked about possibly finding a way to do this within GraphiQL perhaps as some plugin/module.

Although we may want to run the test in the command line, there's some benefits to also being able to run them in the browser.

@jaydenseric agreed to take up an action and help draft a PoC over the next month to explore that. @spawnia please feel free to be as involved as you want to be, but we didn't want to give you a action when you weren't present!

The way I see it, is that a PoC allows us to explore this and see if there are any issues. There's nothing stopping us looking at a couple of PoCs to explore different possibilities if others have some other ideas in mind.

from graphql-over-http.

@spawnia Thanks for volunteering 👍
One more factor: GraphiQL team moved their codebase to TS + Jest and I plan to do the same for graphql-js/express-graphql and since some features (e.g. batching) involve modifying graphql-js, express-graphql, GraphiQL and our future test suite it would be great if we keep it unified.
That said I'm totally for using some other stack if it will provide significant benefits.

from graphql-over-http.

Oh yeah, when i say JavaScript i actually mean TypeScript.

I am going to try out Gauge and Cucumber for a bit and see if they actually simplify writing tests. If not, the combination of Jest + TS looks like a solid pick.

from graphql-over-http.

I'm all for Jest + TS based on my personal experience. Jest is very ergonomic.

from graphql-over-http.

Although we may want to run the test in the command line, there's some benefits to also being able to run them in the browser.

Browser based tests are significantly harder to integrate into build pipelines, both locally for developers and in the CI pipeline. If there is a way to easily run the tests from the CLI and without a browser, we will be much more likely to be able to continuously validate that our GraphQL services follow the spec.

from graphql-over-http.

I don't really see the use case for running them in the browser, i guess it could be a quick way for a one-of check of an API? I would always go for an automatic process that continually asserts spec compliancy of a GraphQL server i develop/depend on.

I think that automatic test execution should be our first priority, so i would focus on a CLI tool first before attempting browser integration. That said, if something like a GraphiQL integration can be tacked on without much additional effort, i am not opposed to it.

from graphql-over-http.

@spawnia Is this issue still relevant?

from graphql-over-http.

Feedback from the July 2022 working group meeting:

• Browser Testing vs. CLI
  • Browsers can not make any kind of request, which would limit capabilities
• Technology
  • JavaScript
  • Get inspired by https://github.com/apollographql/apollo-federation-subgraph-compatibility
  • As few dependencies and as simple as possible
• Errors for MUST, warnings for SHOULD
• Host in a separate repository under the GitHub graphql organization

Thanks everyone for the input, I intend to try implementing something with webonyx/graphql-php#1206

from graphql-over-http.