Component Integration Tests

[00:00:00]
>> Mike: Let's check our tests before we close out this section.
>> Mike: I'm gonna hide the past tests. All right, let's see. Looks like a validation message. So we expected this string here to show up. It was always on the screen. Now it's conditionally on the screen. I'm just gonna update my test for now so that it passes by saying, initially rendered.

[00:00:26]
You should not see that message. So we'll go to login-form-test and delete this last line here, and everything should be good. Yep, there's my green bar up at the top. 66 of 66 passed, we are good to go. So I'm gonna make a commit. And congratulations, we have just completed step eight.

[00:00:59]
>> Mike: Next thing we're gonna do is write a more meaningful integration test. Imitating the process I went through just now to validate that the login form works properly, where we initially make sure the button's disabled, then pick a user, then make sure the button is enabled. So we're gonna have to use some of our test helpers here.

[00:01:24]
I'm gonna leave this in place. We'll change the title of the test at the end but I'll leave this as is. And what I'm gonna wanna do is, effectively, input some data, right. If this were an input, I would be filling in a value. And that is the test helper we're going to use.

[00:01:46]
It's called fillIn.
>> Mike: I am then going to await fillIn, and I'm gonna write a test selector. Let's see, it's probably gonna be the only select component in there. So this is the equivalent of what you would in a query selector, right? It could be a dot class or a hashtag ID.

[00:02:12]
And then the value we're gonna fill in. And one, we've been checking, testing, so it seems like we could use one or two here. And then, so up here I wanna assert,
>> Mike: Button is disabled, and down here it is enabled. So it seems like we need to get a hold of this button, and the way we're gonna do that is find.

[00:02:38]
This is like query selector, except that it ensures that you don't accidentally pick up on parts of the test runner UI itself, where there are inputs and there are dropdowns and things like that. So it's sort of a constrained query selector. You can use it the same way.

[00:02:54]
So up here I'll say, let button = find('input[type="submit"]'). And, let's see. We can then say, assert.equal(button.disabled); and we gotta give VS Code a clue that this value is of type HTML input element.
>> Mike: So the way we're gonna do that is this this comment here, and then we'll just sort of wrap this in parentheses.

[00:03:41]
And let's see, button, did I do that right? Type equals submit. It disappeared my parentheses here, save. Interesting, Prettier is wrestling against me. Sorry, my fault, type. So button.disabled should be true, and then down here, button.disabled should be false.
>> Mike: And let's check out our tests.
>> Mike: Everything looks good.

[00:04:20]
So this is a more meaningful immigration test, and now we can assert that yes, our derived state works. And we have just finished step nine.