Another little question: How do you handle testing the api on the producer side and mocking it for t...

# graphql-kotlin

[dave08]

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?

[Dariusz Kuc]

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)

[Dariusz Kuc]

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

[Dariusz Kuc]

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

[dave08]

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.

[dave08]

There are projects like https://github.com/appmattus/kotlinfixture to generate fake data...

[dave08]

And this seems to be the js version https://graphql.org/blog/mocking-with-graphql/#mocking-is-easy-with-a-type-system

[dave08]

I guess that with graphql on Kotlin, that would still be a quite a bit more work to implement though...

[Dariusz Kuc]

your integration tests would be testing for validity of contract

[Dariusz Kuc]

so hard coding the responses might be ok

[Dariusz Kuc]

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)

[Shane Myrick]

Schema registry is free on Apollo Studio, schema checks are on their paid plans

https://www.apollographql.com/pricing

[dave08]

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.