The example test from the last video is actually already a pretty good one. So it comes with every new Laravel application, and it's also one that I always have in my application. It just makes sure that when we visit our homepage with a GET request, we get a successful response back. This doesn't tell us anything about the page itself or what content you can see on the page, or if there is even some content on the page, but it already helps us by telling us that there is no error. This is the easiest and fastest test that you can write for your application. Even if you have just started testing and you're a beginner, you can do this and you

This is the easiest and fastest test that you can write for your application. Even if you have just started testing and you're a beginner, you can do this and you have your first test, which is just a great starting point into testing. So I want to keep this test for sure, but let's rename the file because it's now not anymore an example test. I want this to be my page's response test. For every new page of our application, I want to add the same test here to make sure that for every page, we get a successful response. It's the first test that I write for every feature that relates to a page. So there are two little things that I want to change here.

It's the first test that I write for every feature that relates to a page. So there are two little things that I want to change here. First, instead of using the object-oriented way to make this GET call to application, we can do this with a function that comes from PEST itself. It's a little GET helper here. And then instead of defining here the route, I want to do this with a route name. So let's imagine we have a route with the name home, which we want to make a request to, and then we can also chain here this assertion. And then instead of making this assertion with a specific HTTP status code, we can also run the OK method, which under the hood, when we check this out, just does the same as before.

And then instead of making this assertion with a specific HTTP status code, we can also run the ok method, which under the hood, when we check this out, just does the same as before. OK, and I also like to have some comments here. So this is the part where we're going to act because we're making the GET request, and then we also have the assertion chained onto it. And that's already TDD. When we think about it, we have changed our test because our test tells how we want our application to work. We want to work with this new route called home. When we run the test, it will fail now because it will not find our specific route home because

We want to work with this new route called home. When we run the test, it will fail now because it will not find our specific route home because we haven't defined it yet. So this means we go back to our route here. Let's give this a name. It's called home. Let's run our tests again, and they are back clean. By the way, you can always see here that the test is passing here at the top or here on the left or here later if we scroll down. All right.

the left or here later if we scroll down. All right. And this is how we created our first real test for application. And we already did a little bit of TDD by changing our test and then making a failing test pass. Welcome to test driven development.