I understand the basic of how graphql work, like we have query and mutation as get and post type request. and in body we have to pass either query or mutation along with it’s variables and auth token. However as this is bit different from REST, there are few things I’m not sure how to begin with. -
What actually is testable.
How to form scenarios.
Which tool is best to automate? (Currently I’m trying to automated using Rest Assured)
With Rest assured I have been trying to pass query and variables separately but it’s not working. I’m getting {“errors”:[{“message”:"Invalid Syntax : offending token '"query.
In general it should not differ a lot from the tests made for a Rest API, with the particularities of Graphql of course ( Query, Fragment, Methods etc).
There is this older article that I think would help. Have a look
You can mostly focus on testing the schema, but more importantly, focus on asserting what the response body is returning. Validating response codes is not needed, since mostly you get back 200 anyway.
Also, try to get creative when testing, for queries (and mutation) that accept parameters see what happens when you send something that isn’t supported, try nesting a lot of fields in a query to see if it has a negative impact on performance.
Postman is pretty easy to set up for GraphQL testing, I used it to explore GraphQL APIs:
I haven’t used it in a job for the last two years, but I remember that Bas Dijkstra (he’s one of the top experts in API testing today) had a tutorial on how to test GraphQL using Rest-assured:
Keep in mind that you not just can test the API (e.g. are paramater validated, is something returned).
But also by the API the underlying system as whole (e.g. is the response correct in relation to the use case, what problems can you find in the processing).
An API is seldom an isolated function on its own, but a gate, like the UI, to the whole application.
I agree, but it depends on what you’re asked to test.
If you see requests that return 200 but the body of the response says “error” that’s a bug!
Yes, that’s why it’s important to pay special attention to the response payload as the status codes aren’t much help, as they are with REST APIs.
so far from what I have learned I believe it’s a bug. However I also got to know that developers can customise return code with error messages gracefully handled.
it’s kinda undefined because graphql is supposed to be independent from the transport layer. You could for example have client and server communicate via websocket. Graphql still works the same but you don’t have any POSTs and http status codes.
As API designer, you can still decide do accompany errors with specific status codes, like when you return 401 when missing authentication. you can argue that this is before involving graphql.
If you go by what graphql defines, then errors are in the response message, and http status codes are not sufficient to check for “success”.
