Transcript from the "Unit & Integration Test Exercise" Lesson
>> 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.