Advanced GraphQL, v2

Testing Resolvers, the Schema, & the Server

Scott Moss

Scott Moss

Advanced GraphQL, v2

Check out a free preview of the full Advanced GraphQL, v2 course

The "Testing Resolvers, the Schema, & the Server" Lesson is part of the full, Advanced GraphQL, v2 course featured in this preview video. Here's what you'd learn in this lesson:

Scott explains why it is easier to set up testing on the back-end, and gives a survey of what resolvers are, how to test them, along with how to test the schema and the serve.


Transcript from the "Testing Resolvers, the Schema, & the Server" Lesson

>> I don't really like testing on the front end. I like testing on the back end because it's so simple, so easy. This unit integration, mock everything out is beautiful front end testing. So painful, so painful like, I mean trying to set up a testing on a framework is like there's a new way every day, and I just can't stand it.

But on the backend is super easy and I'm glad to say with Apollo and graphql, it's probably some of the easiest server testing I've ever had to do. It's like ridiculously easy. So we're going to talk about a few of those things. But let's talk about the different things that you can test and how you would test on the graph do so resolvers, how would you test resolvers and graphql.

Well, I mean they basically just function right so you would do a test on them. They're just methods on an object that they literally know nothing about graphql, they get past these arguments and they execute something. That's it, that's the visual resolvers, they have no association with the framework that's executing them.

They're just a map of methods it's literally just testing those and this is why I like to pass everything in through the context. Because when I'm testing them, I can just mock that whole context object out to be whatever I want. And it just works versus like having all these inputs and trying to mock those out using something like just or sign on whatever you want to do, like I said, you just mock out any data sources that you might use.

So if a resolver is talking to a res client or if your resolver s talking to a database, it's not important that that red client is working. It's not important that that database is working, that's not what you're testing right now, you're only testing the business logic of the resolver.

So you can mock the other stuff out. This is a unit test of the resolver. It's not testing to see if the database query works, you don't really need to know that you might need to know if you pass the right stuff to the database query. But testing at the database responded is not the job of the resolver.

The resolver expecting the database to respond. So and then yeah, mock up all the DB calls. And the next thing is testing a schema. So basically, you can, there's a lot of ways you can test the schema. I mean, the most brutal way to test the schema Is just to do this string, Eagles this string.

[LAUGH] I do not recommend doing that, that is so bad, but you can do it. And I think in one case, we had to do it at one point there was no other way to test the schema that we knew of, we learned a lot better. But yeah, you could have like a string that has tight definitions in it.

And another one in your test like it's got to equal this. And whenever you change your type file someone fall you got to go change it another file, but you don't want to do that because then it gets crazy with spacing and then you gotta try to format it like just don't do it.

The best way is to convert your TypeDefs into a schema. So, for instance if you use that GQO tag that converts the type definition, the schema definition language into an AST which is a JavaScript representation of a schema so now you have an object. Okay. Now, you can compare that object to another object so maybe that's a little better than testing strains so maybe use a GQO tag on your tag definition.

And maybe have something else hardcoded somewhere else and you test it against that, that might be a good way. That's one way to test the schemas. But basically, you can just unit test any of the object types as well just to see if they have the right field on them.

User has first name and its type of string. User has ID and this type is ID unit test that I don't see a lot of people unit testing their schema, stop. One thing that I see a lot but sometimes depending on the application you might need too and our example, we had to because our app generate a schema every time, so we had to make sure that schema was correct.

So we have to test our schema, but if your schema is not dynamically generated like it's read in file like we've been doing all day. Testing scheme is probably not that big of a deal, you're probably more concerned about it changing and people adding things they shouldn't be adding versus, it's passing a test.

So, you probably want to look at something like Apollo's service where you can lock a schema down and prevent it from being changed without different authorization rules and stuff like that. Like a remote schema service that might something a little more interesting. Testing won't cover all those basis.

Yeah, and testing the server, you have integration testing of the entire server and that's kinda we're gonna to be doing today. And that basically is. There's a lot of ways to do it. We're going to do it the Apollo way. First, I just started using the Apollo and maybe a couple months ago, but before that I use just like this standard way, and it still works like both approaches are so good.

It really doesn't matter. But yeah, you basically test the entire service or like, here's a query. I'm going to execute this query and then I expect this result to come back. Like you're testing the whole flow or here's a mutation. I'm going to ask you this mutation. I expect this result to come back through testing the typedefs.

So you're testing the query you sent up, you're testing the schemer, you're testing the resolvers. You're doing all of it. And then you get to pick and choose what you want to mark out, if you will, all of its around sure, make all the run if not mark things out, and we'll go over that approach.

And then the way you do that is basically you create a test client to use to issue queries and mutations with against a testing instance of your server. So because we don't have a client, we're gonna create a fake client on the server that would act as if it was a react or graphQL playground.

And then we're going to create a testing instance of our server. Just like we created an Apollo server. We're gonna create a version of that, that's meant just for testing and it's really cool. From there, like I said, you can mock out whatever you want. variables, context, data sources.

Doesn't matter.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now