-
I'm a bit puzzled when it comes to unit testing a resolver that utilized injected dependencies. We are currently migrating and our API controllers share services with our GraphQL resolvers. We have an issue where services are undefined. I've tried naming services by string identifiers ('NAME_SERVICE') then doing Container.set / Container.gets. Went through Ben Awads videos, but he doesn't touch on dependency injection. We came to a wall with this question asked previously: typestack/typedi#329, that seemed to have been closed due to this not being supported by type-graphql. However, documentation/repository are keen on showing many of examples how to use dependency injection, but no tests around it. Service
Resolver
Test
|
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
Actually, I figured it out. So there's two sets of test you have going on. Unit / Integration. For Unit testing, you want to test the raw "non-containerized" approach. Bascially just raw ES6. You create a mock version of your service class and just pass it as an instance directly to the constructor.
For Integration testing, (actual GraphQL testing), this is where when you build your schema, you just inject your container into your executable schema fixture at bootstrap time of test. so like, beforeAll or something. For integration, in your test file, you need to drop
|
Beta Was this translation helpful? Give feedback.
Actually, I figured it out.
So there's two sets of test you have going on. Unit / Integration.
For Unit testing, you want to test the raw "non-containerized" approach. Bascially just raw ES6. You create a mock version of your service class and just pass it as an instance directly to the constructor.
For Inte…