Advanced GraphQL

Advanced GraphQL Unit & Integration Test Exercise

Topics:

This course has been updated! We now recommend you take the Advanced GraphQL, v2 course.

Check out a free preview of the full Advanced GraphQL course:
The "Unit & Integration Test Exercise" Lesson is part of the full, Advanced GraphQL course featured in this preview video. Here's what you'd learn in this lesson:

In this exericse, students code a unit and integration test.

Get Unlimited Access Now

Transcript from the "Unit & Integration Test Exercise" Lesson

[00:00:00]
>> Scott Moss: So now what you're gonna do is you're gonna take these two examples that I have here. And you're gonna do the same thing for the project.spec. You're gonna write a unit test for the project resolver. And then you're gonna write a integration test for that same resolver.

[00:00:16] It's gonna look very similar to what I did here. And I'm gonna freeze it on this screen. So again, unt itest is just testing the resolver. You're not running a graph field query. The integration test is you're actually running a graph field query that a client would send with the right variables and everything.

[00:00:30] And you're looking at the output and making sure that it is what it should be.
>> Scott Moss: And that's it, and you could just run yarn test to test this. Quick note about the test, if you look at the package.json, a few things here. I have this forceExit, this is to force Mongo to stop.

[00:00:49] Otherwise it won't. It's kind of annoying. And then runInBand, so Jest actually runs all your tests in parallel, which is fast. It's really great, but it kinda messes things up with the database because they run in parallel. And each test relies on a completely clean database. You'll have old codes still in there while other tests are running, which could affect your test.

[00:01:12] So, eventually, you'll have tests that are failing, unless all your tests are optimized. Or unless all your tests is accounting for, there still might be data in the database. But I think when you write a new spec, whenever you write a new test, or a new IT, it should be from a fresh state.

[00:01:30] It should not carry a state from the previous test, so I do runInBand to guarantee that all these ran. Whereas if we don't do runInBand, it will run in parallel to speed things up, but you will have side effects across your database. Like we literally ran into this issue with CircleCI to the point where I cancelled my subscription of Circle series.

[00:01:52] I thought it was CircleCI. It randomly failed in the test, but it was just this. It was just Jest. We still didn't use CircleCI. We went somewhere else.
>> Group: [LAUGH]
>> Scott Moss: Yeah, it wasn't Circle's fault. It was Jest running in parallel. So yeah, it slows it down, but it will at least work.

[00:02:07] So quick note on that.