And what's cool is because of the way Cypress works, when I run things like this, it basically gets added to a chain that will all be executed synchronously, and that way things are as deterministic as possible. It's always going to happen in the same order. So there's no problem here. Now for any test where I begin quiz, I simply call start, and let's see if we can find one. Yeah, don't worry too much about this code, but it remembers the User's score if they have previously completed it. So I'll show you what that means. If the User takes the score, we then record it and save it to the database, and if they

So I'll show you what that means. If the user takes the score, we then record it and save it to the database, and if they then return to the quiz, we remember it, and we immediately show the results page. So here's how I'm testing that. I start the quiz, I answer the questions in the quiz, I assert that I should be on the Review Solutions page, and then if I reload using cypress.reload, I expect to be on the same page after I refresh the browser. And then if we find the button that says Restart Quiz, and I click on it, I'll be back at the cover. And that's how I test it.

All right, let's see how we test that. We start the quiz. Now we try to get an element, and notice this custom data attribute here. We're going to talk about that in just a second. But for now, just imagine it's a CSS selector. So we try to find an element that matches this selector, and that is this button right here. Now, by default, it should be disabled. And notice this syntax here. You can do all sorts of things.

And notice this syntax here. You can do all sorts of things. Like I can say if I don't expect it to exist at all, I could say shouldNotExist. I could expect it to have a specific class or things like that. So it's really flexible in that regard. But in our case, I'm saying once you find this button here, it should be disabled. However, as soon as I make a selection, and notice once again, because making a selection is so common in these tests, I wrap it in a little helper function. chooseA. And what that's going to do at the very top is right here. It'll say Cypress, get the element that matches this selector, and then click on it.

Choose A. And what that's going to do at the very top is right here. It'll say Cypress, get the element that matches this selector, and then click on it. All right, let's go back. Right here. If I make a selection, that should then change this button to not be disabled. Now, on that note, often you'll be working on a single test. Let's open this in Firefox. But you'll notice it wants to run all of the tests every single time I save. Let me stop that. So instead, you can target which tests you want to run by using the dot-only syntax.

Otherwise, stick to a custom data attribute. So you'll see dataCy here. And remember, for HTML data attributes, it can be anything you want. dataFoo, dataBar, dataCypress. It doesn't matter. It's just a key there. So in our case, if we switch back to what I had earlier, right here, let's see what that looks like. Now I happen to have this stored in a QuizFooter view component. And if we scroll down, here is the button that corresponds to this right here.

Now I happen to have this stored in a QuizFooterView component. And if we scroll down, here is the button that corresponds to this right here. And you'll see I do give it a custom attribute. data-cy equals next-question-button. So now think about it. If at any point we decide six months down the line when we're not thinking about our tests, ah, this doesn't need to be quiz-arrow, we'll change that. Or maybe this should be an anchor tag instead of a button. It shouldn't. But you know, if we made a change, we no longer have to worry about our Cypress test.

It shouldn't. But you know, if we made a change, we no longer have to worry about our Cypress test passing. As long as this attribute remains, we're good to go. And again, you can access that element by saying, ah, remember, this is basically a CSS selector. So we're saying basically find any element that has a data-cy attribute of next_question_button. And that's it. You can see I'm using it all over the place.

Okay. So I'm going to take all of those out, and these will now go, hmm, it's going to go right here. Paste those in. Reformat with Prettier. And if we return to Firefox now, here's what we get. Two different states. But yeah, you know what? These, these are related to in progress as well. Let's look for these.

But I like doing describe, context, it. Okay, two more things. So if I switch back to the top, have a look right here. Setting up the necessary state for an application is always the trickiest part of acceptance testing. So what you'll usually want to do is add a before or a beforeEach block. Usually it's going to be beforeEach, but in this case, I could get away with before. Now as we discussed in the last episode, you can submit requests to your server to create a factory or log in a User or perform some other action. However, don't forget you can also just call a standard database seeders, and that's what

a factory or log in a User or perform some other action. However, don't forget you can also just call a standard database seeder, and that's what I'm doing here. So rather than hitting an endpoint to create a QuizFactory, an Eloquent factory, and then doing it a couple more times for the questions associated with the Quiz, it starts to get a little laborious. So in situations like this, database seeders can be really helpful. Here I have a QuizSeeder. I set the necessary environment it should run in. And if you want to take a look at that, it's really simple stuff.

I set the necessary environment it should run in. And if you want to take a look at that, it's really simple stuff. I start by emptying out my quizzes table. And actually, a quick note on that, you could do truncate, but you end up in situations often with foreign keys when you do that where MySQL simply won't let you. So often I'll just do this instead. But yeah, notice I'm just hard coding it. I'm not even using fake data. Create a generic Quiz, add a bunch of questions to it, and that's it. So before the seeder runs, I go ahead and set up my database.

Create a generic quiz, add a bunch of questions to it, and that's it. So before the seeder runs, I go ahead and set up my database. And the reason why it's in the before hook rather than beforeEach is because it's not going to change. My SQL will never delete that data or modify it. So I only have to do it one time for all of the specs here. However, the only downside to this, I think, versus using a traditional model factory approach is it's a little blurry what data is being generated there. And there's not necessarily a one-to-one relationship between this seeder and this test. So if you end up tweaking it in another test, you know, it might get a little fragile.

And there's not necessarily a one-to-one relationship between this seeder and this test. So if you end up tweaking it in another test, you know, it might get a little fragile. You just have to be a little more thoughtful. But anyway, sometimes I will add a little hint to myself what this is doing. Or in other words, it creates an example quiz consisting of three questions, and the solution is a, I don't love this, but I kind of appreciate it six months from now for a quick refresher of what my database should look like. Anyways, it's something you might consider for more complex relationships. And remember, the seeder doesn't have to map to the Eloquent model. So I could say, if we go up to the Make Commands, you have a Make Seeder there.

And remember, the seeder doesn't have to map to the Eloquent model. So I could say, if we go up to the Make commands, you have a MakeSeeder there. So you could say php artisan make:seeder. Any setup you need to construct the world for a common setup or requirement. Okay, finally, let's talk about the dashboard. So I'm going to switch over to Cypress. We're going to go to Runs, and we're going to set up a dashboard here. The project is Lerikast. I'm going to make it private. We'll set that up.

I'm going to make it private. We'll set that up. Okay, so now you'll see in your cypress.json file, it adds a unique project ID, and then there's also a unique key here. So my understanding is those two combined basically authenticate you. So now if we run this, it'll be pushed up to your dashboard, which you can log into, and I'll show you that in just a minute. Let's go ahead and run it. So now we're basically saying run it in headless mode, but we're going to film it, and we're going to push it up to our dashboard.