https://kotlinlang.org logo
#graphql-kotlin
Title
# graphql-kotlin
d

dave08

02/22/2021, 3:55 PM
Another little question: How do you handle testing the api on the producer side and mocking it for tests on the consumer side (for now also Kotlin server-side)? Any special tools for this?
d

Dariusz Kuc

02/22/2021, 4:32 PM
server testing -> you can write whatever unit tests for the target functions, as for integration testing you could start up a server and then post a sample query and verify the response like we do in spring server example (https://github.com/ExpediaGroup/graphql-kotlin/tree/master/examples/server/spring-[…]st/kotlin/com/expediagroup/graphql/examples/server/spring/query)
client testing -> you could either mock your clients directly or use something like wiremock (http://wiremock.org/) to intercept your graphql calls and return some mocked responses
you could also look into the specific graphql client capabilities -> e.g.
graphql-kotlin-client
is built on top of Ktor HttpClient which provides
MockEngine
(https://ktor.io/docs/http-client-testing.html)* *haven't tried it yet but it "should" work fine
d

dave08

02/22/2021, 4:41 PM
Was thinking of wiremock, but testing the query was valid, and mocking the structure of the response could get to be quite a bit of code... The Ktor idea is better for checking the actual queries... but the responses will still need to be hard-coded. But sounds like an interesting option 👍🏼. I guess the ideal would be to have a real graphql server running in the background responding with fake/generated/specified data according to the schema. It seems like there is such a thing for js in apollo... but hard to work with Kotlin server-side.
There are projects like https://github.com/appmattus/kotlinfixture to generate fake data...
I guess that with graphql on Kotlin, that would still be a quite a bit more work to implement though...
d

Dariusz Kuc

02/22/2021, 5:13 PM
your integration tests would be testing for validity of contract
so hard coding the responses might be ok
on the server side you should have some test that verifies that you are not making some backwards incompatible change - through something like Apollo GraphQL Registry (paid) or GraphQL Inspector (oss -> https://github.com/kamilkisiela/graphql-inspector)
s

Shane Myrick

02/22/2021, 5:45 PM
Schema registry is free on Apollo Studio, schema checks are on their paid plans https://www.apollographql.com/pricing
d

dave08

02/23/2021, 3:16 AM
That inspector looks nice! I'm still not sure where the previous schema gets saved to compare it, if it's only generated at run time, I'd have to add some extra runtime logic to save the old schema somewhere before making new changes. The ideal would be to spit those out at compile time, and when commiting in git to go to production have a copy saved in the repo as the current production copy. Then the CI build could fail if some accidental change was made.
6 Views