Laravel Livewire Key aspects for Integration or Unit testing

We will give an introduction to testing specific to Laravel Livewire by introducing its main assertion methods.

The Livewire class and its structure is the same as a class with a test extension so that it is understood that it is a test that extends TestCase:

tests/Feature/Blog/IndexTest.php

namespace Tests\Feature\Blog;

// use Illuminate\Foundation\Testing\RefreshDatabase;
// use Illuminate\Foundation\Testing\WithFaker;
// use PHPUnit\Framework\TestCase;

use Livewire\Livewire;
use Tests\TestCase;

use App\Livewire\Blog\Index;
use App\Models\Post;

class IndexTest extends TestCase
{
   /**
    * A basic feature test example.
    */
   public function test_index(): void
   {
       $this
           ->get(route('web.index'))
           ->assertSeeLivewire(Index::class)
           ->assertStatus(200)
           ->assertSee("Post List")
           // ->assertViewHas('posts', Post::paginate(15))
           // ->assertViewIs('livewire.blog.index');
       ;
   }
}

Which is one of the files that we have here, this one that we have here, in the same way later I had some clarifications with this but it is important that test test case appears here because with this we can use the methods or a set of methods of the get post put delete type so that we can make requests to the routes of our application, that is, the components since that is what we are going to test since by default whether you use pes or whether you use php unit they obviously also have a Test Case class:

// use PHPUnit\Framework\TestCase;
use Tests\TestCase;

But those classes do not implement the get post put delete type methods, that is, to make requests of that type to our application, those are methods that the Laravel API incorporates and that is why we have a class here that implements it, it would be implemented here because they must be implemented, whether it is that here the nesting is a bit strong with the ar classes, but that is a bit of the joke of all this, for the rest we have multiple ways to evaluate the components. Well here, look at this, which is the diskette, the same requests that we have defined and here, for example, it is indicating an assertion method to know if you are using this component internally, that is, if we have a nesting there with the same ones, for example, it can be useful when we want to test the step by step that we have a large nesting there or directly if we are using the buttons from a form for which we have defined by defects in lightware, the buton component, for example, look, are you using the buton component, perfect because you do not have to use another one, if you do not have to use that element that you see here, here we have again a little richer the options that We have if we compare it with inertia that it is a little more closed since there the idea in inertia would be to use the tests directly in Vue and here you can see a little bit through Livewire test:

Livewire::test(Index::class)
  ->assertSee("Post List")
  ->assertViewHas('posts', Post::with('category')

The component and here what the hell are you doing in that component and generate the test Data that we have a thousand ways in Laravel I have my style and well you can use the one you want for the rest there is not much I do not want to get ahead of myself here for example to authenticate the user that we can do directly in the component or in the constructor of the class there are many options really this already depends a bit on you But I simply wanted to present to you that this documentation exists it is quite good and obviously when the basic Laravel is insufficient for us we will directly come here to remove the redundancy to do here adapt our tests in Livewire.

Getting Started with Testing in Laravel Livewire

We are going to start by creating our test finally for what would be the blog module, specifically the index, which is why we created the test that we are seeing here on the screen. It is very important that you run it and see that everything happens correctly:

php artisan test

If it doesn't pass correctly you have to check that it's bad we haven't really done anything then it shouldn't have another output then what is the first thing we have to do here open the controller component whatever we are using here it is important to note that I am going to do the minimum and necessary tests for example a test that we could carry out would be for the filter to test different filters but in order not to complicate the matter too much I don't want to place so many tests and above all here at the beginning suddenly later when we finish it if they request it I can implement it but initially I am not going to implement them I simply want it to enter here without any filter I will test without any filter applied and test what we can see on the screen which would be the list of publications and even if it is also here it may be that we have here the list of categories to do something interesting exactly what can we test here we have the test for the basic Arabic course it will always start like this making the request the status 200 has to return we can put there the name of the view the name of the route things that we see in the view and if we are passing the publications based on what expected are those routine operations and see how far we can go since
remember that here we are not using basic larab if we are not already using iware then things change a little that on the one hand the next thing is the database I would recommend that we duplicate it from now on some problem at least we have the copy and we do not lose the data that we already have there so control c control v or command v like command c and command v and have it referenced here later we configure a database for development but again we are going little by little then it is also important to know what is the route that we are going to test would be the blog one here we have it would be this one exactly this one and we can also see it here So when we are clear about what the route is we can already start something starting by placing the blog one here then we execute here quickly it has to return a 200 since it is the same remember that if you put someone valid it will give you a 404 and here you can see the error you put 200 But this returns a 404 and you have to see what is the problem in this case is the route otherwise:

<?php


namespace Tests\Feature\Blog;


use Illuminate\Foundation\Testing\RefreshDatabase;
use Illuminate\Foundation\Testing\WithFaker;


// use PHPUnit\Framework\TestCase;


use Tests\TestCase;


class IndexTest extends TestCase
{
    public function test_example(): void
    {
        $response = $this->get('/');


        $response->assertStatus(200);
    }
}

Here what I was telling you is tip that is to make get type requests just like it happened with aios when we wanted to make a get postp p delete type request here it is similar we indicate through the method it also indicates which http method is going to be used which in this case is a get type request important that you inherit from here from Test Case since around here to see if I can find it use test case over there there is another one I really don't remember where the test Case was the other one let's see if I find it here quickly Here is exactly this one from the internal to the frw of php unit notice that it inherits it Notice that it takes it But if we execute it here you will see that it fails and it would be because it did not find the method as you can see by AC So for whatever reason or any motive anything strange that changes here in the larabel pencil when we are creating the tests if for any reason it inherits from this this one would not be if not it would be this one which inherits everything we have in php unit or pes depends on what you are using but it also adds things like in this case is the use of
requests through http that are essential for us since we want to test the complete module, that is, we want to test our component-based module, our application, and that is why they are feature type tests and not unit type tests, and that is why they are in this folder because we are not testing individual modules but the application as a whole, in this case it is specific to the blog, so I hope that all this panorama has been clarified and we are going to leave it here, and in the next class we finish carrying out the test, advance as much as we can so that it is using the basic Laravel API and then we start to add things with Laravel based on what has been explained here, the assertion methods specific to Livewire, but we already start that from the next class

First test with Laravel Livewire 3

We are going to start by creating our test finally for what would be the blog module specifically the Index which was why we created the test that we are seeing here on the screen here it is very important that you run it and see that everything passes correctly if it does not pass correctly you have to check that it is wrong we have not really done anything so it should not have another output So what is the first thing we have to do here is open the controller component whatever it is that we are using. Here it is important to
note that I am going to do the minimum and necessary tests, for example, a test that we could carry out would be for the filter, to test different filters, but in order not to complicate the matter too much, I do not want to place so many tests and above all, here at the beginning, suddenly later on when we finish it, if they ask me, I can implement it, but initially I am not going to implement them, I simply want it to come in here without any filter, I will test without any filter applied and test what we can see on the screen, which would be the list of
publications, and even if it is also here, it may be that we have the list of categories here to do something interesting, exactly what we can test, here we have the test for the basic Arabic course, it will always start like this, making the request, the status 200 has to be returned, we can put there the name of the view, the name of the route, little things that we see in the view and if we are passing the publications based on what is expected, these are those routine operations and see how far we can go, since remember that here we are not using basic larab, if we are not already using iware, then things change a little, that on the one hand, the following is the database I would recommend that we duplicate it from now on. If there is any problem, at least we have the copy and we do not lose the data that we already have there, so control c control b or command b like command c and command b and have it referenced here. Later we will configure a database for development but again we will go little by little, so it is also important to know which is the route that we are going to test, it would be the blog route, here we have it, it would be this one, exactly this one, and we can also see it here:

    public function test_example(): void
    {
        $this->get(route('web.index'))->assertStatus(200);
    }

So now that we are clear about what the route is, we can enter something, starting by placing the blog here, then we execute it here quickly, it has to return a 200 since it is the same, remember that if you put someone valid it will give you a 404 and here you can see the error, you put 200. But this returns a 404 and you have to see what the problem is, which in this case is the route, for the rest here what I was telling you is to make get type requests just as it happened with axios when we wanted to make a get post put path delete type request, here it is similar, we indicate it using the method:

 $this->get(route('web.index'))->assertStatus(200);

It also indicates which http method it is going to use, which in this case is a get type request, it is important that you inherit it from Test Case, since here, let's see if I can find it. Use test case, there is another one, I really don't remember where the test case was, the other one, let's see if I can find it here quickly. Here is exactly this one, the one internal to php unit:

// use PHPUnit\Framework\TestCase;


use Tests\TestCase;

Note that it takes it but if we run it from here you will see that it fails and it would be because it does not find the method as you can see. If for any reason it inherits from this one, it would not be if it were not this one which inherits everything we have in php unit or pest depending on what you are using but it also adds things like in this case is the use of requests through http that are essential for us since we want to test the complete module, that is, we want to test our component-based module, our application and that is why they are feature type tests and not unit type and that is why they are in this folder because we are not testing individual modules but the application as a whole in this case it is specific to the blot. So I hope that all that panorama has been clarified and we are going to leave it here and in the next class we finish carrying out the test, advance as much as we can so that it is using the basic Laravel Api and then we start to add things with lare based on what has been explained here the specific assertion methods for iware but we already start that from the next class.

Base Testing in Laravel Livewire 4

Okay, important aspects here, apart from this way we can use named routes with all the benefits that this brings us, the same thing that we introduced in the basic Laravel course, which would be that if we change, suppose we change the blog route here and we put I don't know a little block or something like that, we don't have to change the tests since they are referenced by name, in this case I think it's web.Index, so we put web.
Index:

public function test_index(): void {
  $this->get(route('web.index'))
}

And so we take advantage and configure a named route to access it, then what was commented here we could change the route and everything will continue working correctly, which would not happen if we left it like this:

public function test_index(): void {
  $this->get('blog')
}

Always run your tests every little change

Since it's going to give a 404 here and it's because of what was commented then here it runs well the adamos with a name I don't know what the hell this is I'll come back here and perfect never always I recommend that every time you make small changes if you're not very used to unit tests go here executing this it runs very quickly especially at the beginning we have practically no tests so that is another recommendation that I can give you make small changes as soon as this can be complicated or interpretable run the test and if you have a problem then there you can find it in an early phase without going crazy then seeing where the problem is.

Test code 200

I guess if the page was found the bad thing is that they are not classified but they appear in order eh of the dictionary if it was not found okay which is the same as setting status 200 Then we do some variants html redirects well we have all this then that is what we have available they are in the end conditionals as I presented to you but they are not sometimes so generic conditionals that they evaluate as who says that the values ​​are exact but they can also
already apply for example that the user is authorized that is authenticated for example then we already have one that already does all this for us for free and need for us to navigate to the response or anything like that arel already does it automatically through this assertion method and also here we have certain assertion methods specific to Laravel if we are using the Laravel Test Case then in this case since we want to ask for the view we have here the one to do view is and we place which view is supposed to be used:

Livewire::test(Index::class)
    ->assertSee("Post List")
    ->assertViewHas('posts', Post::with('category')
        ->where('posted', 'yes')->paginate(15))
        ->assertViewIs('livewire.blog.index')

And here we put the semicolon here remember that you can go by ordering it, that is to say we have the one that is the first and then from there we take out the rest including the one of 200

You can see the exact answers with:

->assertViewHas('posts', function ($posts){
    dd(Post::paginate(15));
     dd($posts);
})

It helps a lot because we have all the content, that is to say, we have all the content of the page and it is going to be cut, which is surely going to happen around here, but we see a page that does not help us much, so well, at least it seems that we cannot expand this assertion method, so we leave it commented there, it is a bit the purpose of this class to see what we can use.

Evaluate important parameters

We can also use Livewire::test() to evaluate a Laravel Livewire component:

***
use Livewire\Livewire;

class IndexTest extends TestCase {
  public function test_index(): void
   {
       $this
           ->get(route('web.index'))
           ***
       ;

        Livewire::test(Index::class);
   }
}

And from here, we can use the assertion methods that we couldn't use before:

tests/Feature/Blog/IndexTest.php

***
use Livewire\Livewire;

class IndexTest extends TestCase {
  public function test_index(): void
   {
       $this
           ->get(route('web.index'))
           ***
       ;

         Livewire::test(Index::class)
           ->assertSee("Post List")
           ->assertViewHas('posts', Post::with('category')
               ->where('posted', 'yes')->paginate(15))
               ->assertViewIs('livewire.blog.index')
       ;

   }
}

Integration and Unit Testing - Testing - Laravel Livewire 5

Now we are going to introduce some Livewire assertion methods that we could extend for this here we can come to the official documentation:

https://livewire.laravel.com/docs/testing

We will see a test method for the components which is the one we should use:

 Livewire::test(CreatePost::class)->assertStatus(200);

So perfect then as who as who says this would be the way we would have to do these evaluations well what else could we do here we are going to see the official documentation here you can evaluate texts among any other assertion method that we do in basic Laravel:

Livewire::test(Index::class)
            ->assertSee("Post List")
            ->assertViewHas('posts', Post::with('category')
                ->where('posted', 'yes')->paginate(15))
                ->assertViewIs('livewire.blog.index')

The pagination, that is, the pagination of our record, what you want to test here is up to you, but this is what we have here:

Livewire::test(Index::class)
        ->assertSee("Post List")
        ->assertViewHas('posts', Post::with('category')
            ->where('posted', 'yes')->paginate(15))
            ->assertViewIs('livewire.blog.index')

So that you can understand how the check works, we can put a debug of exactly this here so that you can see that it will be exactly the same:

dd(Post::with('category')
           ->where('posted', 'yes')->paginate(15))

That's it, and there we have it, so I think it's a little clearer how all this works.

04-12-2024 - Andrés Cruz

En español

• Category
• /
• Laravel
• /
• Laravel Livewire Key aspects for Integration or Unit testing