Now that we can see our purchase courses on a dedicated dashboard and we know the code is working, it's time again to clean it up a bit by refactoring. When we run all of our tests again, you will see that we have some new tests in here and some of them are skipped or even risky. And that's because by installing Jetstream, we also receive those new tests inside our application. Normally, when we use some kind of package, you don't just get those tests inside your app because it's okay when those tests just live inside the package. But with Jetstream, it's a little bit different because now a lot of the code from the package also lives in our application.

But with Jetstream, it's a little bit different because now a lot of the code from the package also lives in our application. And that's why it's a good thing that we also have those tests here. But as you've seen, we don't need all of them. So I think it's a good idea to get rid of some of them here. First I want to keep them in a separate directory because they belong together. Again with past tests, we can just move them around, open up a new directory, bring them in, and all of the tests will still work and we don't have to think about changing namespaces. And we've also seen that some of those tests are skipped and that's just because we don't use those features from Jetstream yet.

And we've also seen that some of those tests are skipped and that's just because we don't use those features from Jetstream yet. Let me show this to you again. Yeah, like here, seven skipped tests and one risky one. And if we scroll to one of them, you can see, yeah, for example, API support is not enabled and this is why this test is skipped. And currently I also don't want to use them. That's why I think it's a good idea to delete them. Okay, let's select all the features that we currently don't need and delete them. And if we run our tests again, everything should be green now, yeah, and there are no

Okay, let's select all the features that we currently don't need and delete them. And if we run our tests again, everything should be green now, yeah, and there are no more skipped tests anymore, which I think is way better than before. If we ever decide that we want to use those features again in Jetstream, we can still bring those tests in. But I like to code for today and not for tomorrow because, yeah, we never know what other things that we probably maybe need in the future. And today we don't need them. All right, so far so good. Let's check out our routes file.

All right, so far so good. Let's check out our routes file. And here we've added now the new dashboard page and yeah, already set page. And for all of other pages, we were using a pages prefix. So let's do this here as well, pages/dashboard. And now I think several tests will fail because this dashboard route has been used quite a lot. So what we can do now is check all of the failing tests again and then try to fix the route where we have used it, but I also can just replace them. And you can see I have already done this before and it seems phpStorm is saving those strings.

route where we have used it, but I also can just replace them. And you can see I have already done this before and it seems phpStorm is saving those strings here. So we're looking for a route where we're using just the dashboard and we want to replace it with pages.dashboard. And we can also see there are some navigation files where this is being used and then also insert our two tests here. All right, replace all of them. Looks good. And now we're running our tests again.

Looks good. And now we're running our tests again. Yeah, we are good. So now we have more consistency with our pages with the dashboard as well. Another thing that I noticed is when we install chat-stream, chat-stream also added here this RefreshDatabase trait to this user's call inside our pest configuration, which is actually quite good when I think about it. We have defined that all the tests that touch the database are feature tests. So why not already call this here for all the feature tests? But this also means now we don't need to run the RefreshDatabase trait inside every single test.

So why not already call this here for all the feature tests? But this also means now we don't need to run the refreshDatabase inside every single test like we have done before. Okay, let's start in the PageCourseDetailsTest here we've been using the trait. So don't forget to get rid of namespace also now DashboardTest, PageHomeTest and PagesResponseTest. And we also have some not an example test, but inside our models here, CourseTest and also inside the UserTest. Let's run our tests again. And yeah, they are just providing us with information that still everything is working.

Let's run our tests again. And yeah, they are just providing us with information that still everything is working as expected. But now we have defined that we want to refresh a database inside our pest configuration. But there's another nice trick that I want to show you here. We might also have feature tests that don't touch the database, like for example, the response test for the homepage. For those tests, we don't actually need to refresh the database. Just when we can use the lazilyRefreshDatabase trait added by Luke Donning to level some time ago.

Just when we can use the lazily refresh database trait added by Luke Donning to level some time ago. With that now in place, the database only gets refreshed when we really make calls to the database. So this is pretty cool now, especially for performance and when we have lots of tests in our application. And since we're already here in the pest configuration, let's also talk about another helpful function that I like to use in all of my applications. We already have here an example function, something. And the one that I like to use in all of my applications is loginAsUser.

We already have here an example function, something. And the one that I like to use in all of my applications is loginAs User. And let me tell you why we need this. So in a lot of our tests, we are creating User mostly so that we can log in like here. I think here's a better one. We're creating the User and the only time where we use this User is here to act as a User. So in this test, what we can do is we can also use the actingAs function. Let's input this function. So yeah, this test is now also working.

Let's input this function. So yeah, this test is now also working. So that's a nice helper method already. But what I don't like is I only create now here this new User so that I can pass it in here. So wouldn't it be way cooler if we don't need to create the User at all and just run it like this? Yeah, I think so. And that's what I do with my new helper method. So as an argument, we want to get in here the User if there is already one.

And that's what I do with my new helper method. So as an argument, we want to get in here the User if there is already one. But if not, we want to make it null. So this means we can create our own User. And then if we create a new User, we want to return it as well so that we can use it inside our tests. So first we check here if the User is given, then we want to take the given User. But if not, we want to create a new one. So let's create a new User with factory and then create. Okay, cool.

So let's create a new User with factory and then create. Okay, cool. So at this point, we already know that we have a new User. And then in here, we can now use the actingAs helper method to log in this user. And then as mentioned, in the end, we want to return the User because we might want to use it. All right, now in our test, we want to give it a try. Let's run the test. And yeah, it is working. And now we have one line which we don't have to write anymore here where we have created.

And yeah, it is working. And now we have one line which we don't have to write anymore here where we have created the User. This is now a nice helper method, which is also very easy to read and to understand what's going on. Okay, let's check all the other tests here. And we don't need this here anymore. This is fine. Here we create a new User because we want to create a User with a cause. And that's a good idea to use our method as well.

Here we create a new User because we want to create a user with a cause. And that's a good idea to use our method as well. logging as user, but now we are using the already given user. This test also passes and I think this is now way better than before. This is the one which we already did. I think that's another example where we're creating just the user. Oh no, here we need the user. Okay, let's keep the user. But still, we want to make use of our new helper method, logging as user. And again, if we have a user, we want to provide it.

But still, we want to make use of our new helper method, logging as user. And again, if we have a user, we want to provide it. Same here. And I think we can do the same inside our page response test. Take a look. The first one is good. And by the way, this is the example here where I make a request to the homepage. It's a feature test, but we don't need the database because we don't need to check if there's anything shown on the homepage. Okay, what about here?

there's anything shown on the homepage. Okay, what about here? This is good. Yeah, here we have another example. We are only creating the User just so that we can pass it in here and log in. And now this should work like this as well. Yep, exactly. All right, let's run all of our tests. And this looks good to me. Maybe just to be sure, let's look for acting as.

And this looks good to me. Maybe just to be sure, let's look for actingAs. Do we have this in some of our tests? We do have this in some of the chat stream tests. But I'm fine with keeping it there. Yeah. Okay, so I think in all of our tests, we have changed this now. And I think this is way better by using now our custom function, which is pretty easy to use. Just write it here inside your pass configuration file and you can use it everywhere.

to use. Just write it here inside your pass configuration file and you can use it everywhere. Okay, cool. I think we have improved the code from the last videos a lot and we are ready to move on to our next task.