Fork me on GitHub

is this a good place to ask lacinia questions?


Yes, it's a shame history only goes so far, otherwise you could see about 50% of this channel is exactly that.


I've implemented field preview in a resolver using executor/selects-field?. That seems to work well. My question is, how do I test that resolver by itself, outside of the context of a full query? I see that the lacinia unit tests use parse-query and parse-query->context here . Is there no simpler way to create a mock context?


> My question is, how do I test that resolver by itself, outside of the context of a full query? You can pass in a context map to your resolver with the fields listed in the context, right?


Like for example (defn resolver [context args parent] …)


I don't encourage people to do this, as the internals and structure could change at any time. What I'd appreciate would be, if you go down this path, to report back so that we can address it properly in the framework somehow, perhaps functions to assemble a context reflecting the state you wish to test.

👍 4

That being said, when we test our GraphQL we essentially pass full and correct queries in and assess the result map. We often mock out databases and external services in some way, but generally exercise the resolvers as-is.


That leverages lacinia to, for example, validate that the raw value returned from the resolver is valid, and deals with cases of a resolver returning a wrapped result, or an asynchronous resolver result promise, etc.


Effectively, we don't unit test resolvers per-se, we integration test queries into our schema.


In fact, I prefer to override things and actually send the request in via HTTP to truly see if it is working end-to-end. This can still be amazingly fast within a test suite, especially if your component system can persist between test functions.

👍 4

This is what we usually do too.. we’ll stub out the selects-field? and then test conditional logic of the resolver (rather than building out the context with lacinia internals) and instead run a pedestal test servlet to test end-to-end thru HTTP calls. This is good information though to avoid doing this in the future.


You could build out a context with this in it to test out any conditional behavior around selects-field? if you needed to, not sure if there’s a better way

{:com.walmartlabs.lacinia.constants/parsed-query {:selections [{:field-definition {:qualified-name :Something/something}}]}}