Basic test

- [Narrator] Laravel, as you might suspect, has a lot of functionality to make it quick for us to get up and writing some tests for our code bases. Let's walk through a basic feature test. A feature test is where Laravel's going to differ the most from writing a straight forward PHP unit test. A feature test is where we can write a test to ensure that some feature that our user might interact with, such as seeing the list of room types when visiting the index page, is visible and works as we expect it to. To start with, we're going to use our terminal application. Inside of here, Laravel provides and artisan make command to generate our basic feature test. We are going to do this we are going to this php artisan make:test ShowRoomsControllerTest. Now, go to our text editor and open up the feature test that it was created for us. This file is located at test, feature, ShowRoomsControllerTest.php. This is a standard Lavavel feature test. You'll note on line 16 that it already starts giving us a heads up on working with our test. Lets see how a basic test might work. We'll look at our web routes file at routes, web.php. You'll see that there's a /test url. That should just return the string goodbye. Lets write a test for that to see how basic a test can be. In our featured test file going back to our ShowsRoomsControlerTest. Lets replace line 18 with "this->get/test". On line 20 we can build up using a fluid interface rassurations to the response. We'll leave in that the status is 200 as we excpect it to be. But we will also add on line 21 "->assertSeeText" and pass end the string "Goodbye". And now we'll open our test. To do this we will go to our terminal application. And run the command "phpunit./tests/Feature/ShowRoomsControllerTest.php. This says, to call php unit and we are passing in the exact file that we want to run our test over. In this case our ShowRoomsControllerTest file. We'll see this test spin up, and it will run and pass our test. We can also run the entire suite of php unit test with "phpunit" alone. You'll see in that case we run three separate test. So now that we know a bit of how this works, lets go ahead and build up a real test. Go back to our editor, and replace line 18 with accessing our /rooms index page. Line 20 is going to be the same with insure that we 200 response. And line 21 we are going to replace that "assertseetext(Goodbye)" with "assertseetext(type). Recall our headers in our Rooms index page has a collum that includes the type of room that it is. After that we can add some more insertions. For instance, we can assert that a praticular view is displayed. Write on line 22 "->assertViewIs" and pass end the string (rooms.index) for what view is being displayed. We can even assert that our view has a variable set. We will do this with "assertviewHas" and pass end the name of the variable. In this case (rooms). So our test is accessing a route. It verifies the route works by asserting a 200 htpp response code. Which is essentially, that the page is visible and it's a normal response. That some particular text is displayed, a particular view file is used, and finally that our view has the particular varrible pass to it. Go back to our terminal application and we'll re-run this text. You note this time, we now have one test and four assertions. Recall what these methods are. assert, assert, assert. These assertions say that this must be true in order for our test to pass. So, we have four separate assertion, operating on this single feature that we are hitting in our application. So, we wrote our first test in a couple minutes. And now you should have more confidence in the future, when we're working inside of this applications and when we're working on that rooms controller. You can always ensure, first off, that it always works, that you always see that type text displayed, that the correct view is displayed, and that there's always the variable rooms passed in.