Transcript from the "Integration Tests Demo" Lesson
>> Kent C. Dodds: Okay, so for this one, lots of the same concepts that we've talked about with unit test actually work with the integration test stuff. And so I'm going to just show the solution of what I would, of the registration form. And then you're going to work through the login form, which is very similar.
[00:00:27] And I do have some instructions in the comments, but just to give you a feel for what it takes to do integration tests from a UI perspective. So let me just get rid of a couple of these things. Okay, so you're gonna do the login form, and I'll show you the registration.
[00:00:51] So here in app.register. Sorry, and these files are in client source test. And so they're a higher level because they're covering many files. They are co-located because the app is just right next to it. So yeah. So when we're dealing with a higher level thing where you often have to worry about things like authentication and the more general global state of the app, and so here the authentication strategy for this application uses local storage.
[00:01:29] So before each one of our tests, we want to make sure we're not in an authenticated state, because we're testing registration. And so we'll remove any token, if there is any and then, I'm not going to go too deep into how the axios mock works, but there is this mock property on it that can reset everything so that you're in a clean state before you start making requests and things like that.
[00:01:52] So we're mocking the requests. In integration tests with UI, yeah, you just don't make any network requests. You save that for your end-to-end tests. And then there's this initAPI thing, that's kind of an implementation detail of this test as well. But in all of, sorry, of this application.
[00:02:11] But in all of these, like wherever you are going to be testing this or doing integration testing, you are gonna have some sort of initialization of the app, like here we are going to load our [INAUDIBLE] or whatever else we have got to do. And you can do that in a before all, or before each, whatever makes the most sense.
[00:02:29] You could also configure that in a setup file or a setup test framework script file. So whatever you need to do to set up the environments so it's ready for testing. With integration testing, you often have to do a little bit more than that. Okay, also with integration testing, normally you're gonna be doing some things that are making async requests or test as async here, and then we're doing this render with router thing.
[00:02:55] So with, especially if you're doing ReadX or react router or anything where it exposes a provider for you, Unstated has a provider. If you try to render anything that needs that provider to provide things in context, and you try to render it, it's gonna blow up and make everybody sad.
[00:03:22] And so this goes back to a question I think you asked earlier, about with ReadX, if you try to render a connected component that hasn't been established, or maybe that was you, then things blow up. So what my suggestion is, that you just render it with the provider.
[00:03:40] And so this render with router actually is coming from til-client-test-utils, which I've configured just to be able to resolve that to client/test. So anything that's in client/test we can import as if it's a known module, so we don't have to worry about dot dot slash, dot dot slash.
[00:03:58] And because you're interested in configuration here, I'll just show you that's pretty straightforward. It is module paths. So anything in the search directory or the test directory can be imported as if it's a node module. It's pretty cool.