Writing tests for an application is a great software development practice. Often, it is the first coding task to be performed before building the features of an application. As the first coding task, tests are initially written to fail because we have no code to satisfy the requirements of the test. Once our tests fails, we can can then build our application to pass our tests. This practice ensures our code meets specified software requirements. It also serves as a guide when extending our application or when refactoring. This practice is commonly known as “Test-driven Development” (TDD).

In this guide, we are going to look at how to write tests for an existing Laravel application.

Prerequisites

  • Basic knowledge of PHP and Laravel
  • Have Composer installed on your local machine
  • Have PHP setup on your local machine
  • Git installed on your local machine
  • A clone of this project

Introduction

There are different types of tests you can run on your application. There is unit testing, which focuses on testing the functionality of a little part of your application like a handful of methods or a class.

There is also feature testing that tests that an entire feature actually works. At this point, you can test many classes and methods, or an entire package depending on how your application is structured.

There is also integration testing which looks at how the different parts of your application couple with each other. Integration tests are always important when building large-scale applications with many functional units. These tests help make sure that each part of your application will work as it ought to. It also ensures other parts relying on them do not fail due to their error.

This first paragraph of Laravel’s testing guide reads:

Laravel is built with testing in mind. In fact, support for testing with PHPUnit is included out of the box and a phpunit.xml file is already set up for your application. The framework also ships with convenient helper methods that allow you to expressively test your applications.

This shows we have the right foundation for building a test-driven application. We are going to take advantage of Laravel’s provision for testing to set up a testing environment.

Setting up the application

We are going to write tests for an e-commerce application built with Laravel and Vue. Click here to view the project on Github. Set up the project on your local machine before you continue with this guide. Setup instructions are in the readme file.

If you want to see how the sample app was built, you can work through the tutorials, starting with Build an e-commerce application using Laravel and Vue – Part 1: Setting up the application

Setting up the our testing environment

Laravel ships with a phpunit.xml file that contains settings your phpunit will run tests with. If you wish to change these settings, you can do so from the file or create an .env.testing file.

The phpunit.xml file contains environment variables that will define how your application runs when testing. You can set up a different database configuration for testing to preserve the integrity of the data you have. You can also set different configurations for sessions, caching, queues, emails or even third-party tools.

If you are building applications with sensitive data, always use a different database for testing. Depending on your application needs, you might want to use sqlite as your test database.

We are going to create a separate configuration file for testing. Create a .env.testing file and add the following code:

    APP_NAME=Laravel
    APP_ENV=testing
    APP_KEY=base64:5CpEFQ9UTR543dbJUsT3araoSSyxuN8NF92gCJJXpk8=
    APP_DEBUG=true
    APP_URL=http://localhost

    LOG_CHANNEL=stack

    DB_CONNECTION=sqlite
    DB_DATABASE=/absolute/path/to/test.sqlite

    BROADCAST_DRIVER=log
    CACHE_DRIVER=array
    SESSION_DRIVER=array
    SESSION_LIFETIME=120
    QUEUE_DRIVER=sync

    MAIL_DRIVER=array

Next, create the database/test.sqlite file:

    $ touch database/test.sqlite

Now, migrate and seed the test database:

    $ php artisan migrate --seed --env=testing

Adding --env=testing flag will tell laravel artisan to use the test configurations we made in .env.testing file.

Now, we are set to start writing our tests.

What should you test?

This is a common concern many people have when they start out with test driven development. It has no right answer. It is not difficult to determine once you know the requirements of the application.

The first thing you may want to do is write tests for every class you create. You would want to assert it actually executes and returns the kind of response you want. You also want to ensure that the response returned contains accurate data, and does not only come in the right format. You would also want to be sure your code does not break when wrong data is passed, or an exception does not cause your entire system to malfunction.

You should automate everything you would test manually. You can test the page rendered to the client to be sure it contains the right information. You can test that buttons click, links go to the right place, forms act as they should, you can also test to ensure certain information exist on a page.

The great thing about tests is that they are automated and can be run many times without any room for error. Tests will identify gaps in your code and will also help you know when you built a feature right.

Writing our test cases

For the e-commerce application, we will be writing tests for each unit of our application. We want to write tests to ensure that:

  1. Products, User and Orders can be created, read, updated and deleted.
  2. A user can place orders that are valid.
  3. A user cannot place an order for a product that does not exist.
  4. An administrator can confirm an order has been shipped.
  5. A user’s order will be updated when it has been shipped.

We will be testing all the API endpoints to ensure it actually works as expected. If we had observers or repositories that handled complex application logic, we may want to test them to ensure they work as expected. This is because errors that we may encounter from the API endpoints would originate from there.

Since our sample application is simple and lean, we will be testing the API endpoints instead.

Testing the product endpoints

To test the product endpoints, run the following command in your terminal to create the test class:

    $ php artisan make:test ProductTest --unit

Now, open the tests/Unit/ProductTest.php file, you should see the template created for us to work with.

    <?php

    namespace Tests\Unit;

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

    class ProductTest extends TestCase
    {
        /**
         * A basic test example.
         *
         * @return void
         */
        public function testExample()
        {
            $this->assertTrue(true);
        }
    }

We are going to replace the contents of ProductTest with seven different test methods.

testCreateProductWithMiddleware

The first test we will create is a test that tries to create a product without an authentication token. It will act as if a user who is not logged in tries to create a product. For this test to pass, the test must return a 401 Unauthenticated HTTP code and will not create a new product. If this test fails, it means an unauthenticated user can create a product on this application. We will know what to fix right away. Insert the code below into the ProductTest class

    [...] 
    public function testCreateProductWithMiddleware()
        {
                $data = [
                        'name' => "New Product",
                        'description' => "This is a product",
                        'units' => 20,
                        'price' => 10,
                        'image' => "https://images.pexels.com/photos/1000084/pexels-photo-1000084.jpeg?auto=compress&cs=tinysrgb&dpr=2&h=650&w=940"
                               ];

            $response = $this->json('POST', '/api/products',$data);
            $response->assertStatus(401);
            $response->assertJson(['message' => "Unauthenticated."]);
        }
    [...]

testCreateProduct

In this test, we will use factory(\App\User::class)->create() to create a fake user object using the factory helper in Laravel. It creates the user object and prefills the contents of the fillable array we defined on the user model.

We will use the fake user created to make an XHR request to our API like this $this->actingAs($user, 'api')->json() and get a full response object. We will check to ensure that the response object contains a success HTTP status code 200 Ok.

We will also check that the JSON response returned from the request contains some arguments. After which, we check that those arguments contain some data using $response→assertJson().

    public function testCreateProduct()
    {
       $data = [
                        'name' => "New Product",
                        'description' => "This is a product",
                        'units' => 20,
                        'price' => 10,
                        'image' => "https://images.pexels.com/photos/1000084/pexels-photo-1000084.jpeg?auto=compress&cs=tinysrgb&dpr=2&h=650&w=940"
                    ];
            $user = factory(\App\User::class)->create();
            $response = $this->actingAs($user, 'api')->json('POST', '/api/products',$data);
            $response->assertStatus(200);
            $response->assertJson(['status' => true]);
            $response->assertJson(['message' => "Product Created!"]);
            $response->assertJson(['data' => $data]);
      }
    [...]

testGettingAllProducts

Here, we call the API for returning all products and check the status code is 200 Ok. We also check to ensure that the data it returns takes a certain structure with certain arguments. We do not know the data returned, but if the data takes a particular structure, then we are sure it would be accurate.

This is an important assertion that is useful when you are returning a large dataset.

    [...]
    public function testGettingAllProducts()
    {
            $response = $this->json('GET', '/api/products');
            $response->assertStatus(200);

            $response->assertJsonStructure(
                [
                    [
                            'id',
                            'name',
                            'description',
                            'units',
                            'price',
                            'image',
                            'created_at',
                            'updated_at'
                    ]
                ]
            );
        }
    [...]

testUpdateProduct

For this test, we will make a call to the products API endpoint to get all available products. Next, we pick the first product returned by the endpoint. This is an important step, so as to ensure that we are updating an actual product and do not have the API throwing errors.

After picking an actual product, we then try to update the name of the product and check that the response message we get is correct for when the product is updated.

    [...]
    public function testUpdateProduct()
    {
            $response = $this->json('GET', '/api/products');
            $response->assertStatus(200);

            $product = $response->getData()[0];

            $user = factory(\App\User::class)->create();
            $update = $this->actingAs($user, 'api')->json('PATCH', '/api/products/'.$product->id,['name' => "Changed for test"]);
            $update->assertStatus(200);
            $update->assertJson(['message' => "Product Updated!"]);
        } 
    [...]

testUploadImage

To test this endpoint, we will need to include an UploadFile class into our ProductTest class.

    [...]
    <?php
    use Illuminate\Http\UploadedFile;

    use Illuminate\Foundation\Testing\WithFaker;
    use Illuminate\Foundation\Testing\RefreshDatabase;
    [...]

We will use the UploadedFile class to create a fake uploaded image file and then test that image upload works. Since the response data is the full image path based on the application, we will check that the response returned is not null.

    [...]
    public function testUploadImage()
    {
            $response = $this->json('POST', '/api/upload-file', [
                'image' => UploadedFile::fake()->image('image.jpg')
            ]);
            $response->assertStatus(201);
            $this->assertNotNull($response->getData());
    }
    [...]

testDeleteProduct

This test acts the same way testUpdateProduct test works, except we send a DELETE request instead of a POST request.

    [...]
    public function testDeleteProduct()
    {
            $response = $this->json('GET', '/api/products');
            $response->assertStatus(200);

            $product = $response->getData()[0];

            $user = factory(\App\User::class)->create();
            $delete = $this->actingAs($user, 'api')->json('DELETE', '/api/products/'.$product->id);
            $delete->assertStatus(200);
            $delete->assertJson(['message' => "Product Deleted!"]);
        }
    [...]

That concludes the all test needed for the “Product” endpoints. Next, we will test all “Order” endpoints.

Testing the order endpoints

To create the test class, run the following command:

    $ php artisan make:test OrderTest --unit

Now, open the tests/Unit/OrderTest.php file, you should see the template created for us to work with.

    <?php

    namespace Tests\Unit;

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

    class OrderTest extends TestCase
    {
        /**
         * A basic test example.
         *
         * @return void
         */
        public function testExample()
        {
            $this->assertTrue(true);
        }
    }

We will write all our test functions inside the OrderTest class.

testCreateOrder

In this test, we will use a fake user to make an XHR post request to XHR post request to our API. We check if the response object has the success HTTP status code 200 Ok.

We will also check that the JSON response returned from the request contains some arguments. We will also check to ensure that those arguments contain some data since that is what we are expecting. Finally, we will check the structure of the data to be sure it contains the right information.

    [....]
    public function testCreateOrder()
    {
            $data  = [
                        'product' => 1,
                        'quantity' => 20,
                        'address' => "No place like home"
                    ];
            $user   = factory(\App\User::class)->create();
            $response = $this->actingAs($user, 'api')->json('POST', '/api/orders',$data);
            $response->assertStatus(200);
            $response->assertJson(['status'        => true]);
            $response->assertJson(['message'       => "Order Created!"]);
            $response->assertJsonStructure(['data' => [
                                    'id',
                                    'product_id',
                                    'user_id',
                                    'quantity',
                                    'address',
                                    'created_at',
                                    'updated_at'
                            ]]);
        }
      [...]

testGetAllOrders

For this test, we will call the endpoint responsible for returning all orders and check that the status code returned is 200 Ok. We will also check that the data it returns takes a certain structure containing certain arguments.

    [...]
    public function testGetAllOrders()
    {
            $user             = factory(\App\User::class)->create();
            $response         = $this->actingAs($user, 'api')->json('GET', '/api/orders');
            $response->assertStatus(200);
            $response->assertJsonStructure(
                    [
                            [
                                    'id',
                                    'product_id',
                                    'user_id',
                                    'quantity',
                                    'address',
                                    'created_at',
                                    'updated_at'
                            ]
                    ]
                );
        }
    [...]

testDeliverOrder

Here, we will make a call to the endpoint responsible for returning all available orders, then we pick the first order. We try to deliver the order and get the data from the response.

We will examine that data to ensure that the is_delivered attribute is true and that it has the same id as the order we actually tried to update.

    [...]
    public function testDeliverOrder()
    {
            $user      = factory(\App\User::class)->create();
            $response  = $this->actingAs($user, 'api')->json('GET', '/api/orders');
            $response->assertStatus(200);

            $order     = $response->getData()[0];

            $update    = $this->actingAs($user, 'api')->json('PATCH', '/api/orders/'.$order->id."/deliver");
            $update->assertStatus(200);
            $update->assertJson(['message' => "Order Delivered!"]);

            $updatedOrder = $update->getData('data');
            $this->assertTrue($updatedOrder['data']['is_delivered']);
            $this->assertEquals($updatedOrder['data']['id'], $order->id);
        }
    [...]

testUpdateOrder

Here, we will make a call to the endpoint responsible for returning all orders and check that the status code is 200 Ok. Next, we will pick the first order and try to change its quantity. We will check the response we received and ensure that it contains a status code of 200 Ok. We will also check that the message returned after updating the order.

    [...]
    public function testUpdateOrder()
    {
            $user      = factory(\App\User::class)->create();
            $response  = $this->actingAs($user, 'api')->json('GET', '/api/orders');
            $response->assertStatus(200);

            $order     = $response->getData()[0];

            $update    = $this->actingAs($user, 'api')->json('PATCH', '/api/orders/'.$order->id,['quantity' => ($order->id+5)]);
            $update->assertStatus(200);
            $update->assertJson(['message' => "Order Updated!"]);
        }

    [...]

testDeleteOrder

This test acts the same way testUpdateOrder test works, except we send a DELETE request instead of a POST request. The goal is to successfully delete an order.

    [...]
    public function testDeleteOrder()
        {
            $user     = factory(\App\User::class)->create();
            $response = $this->actingAs($user, 'api')->json('GET', '/api/orders');
            $response->assertStatus(200);

            $order    = $response->getData()[0];

            $update   = $this->actingAs($user, 'api')->json('DELETE', '/api/orders/'.$order->id);
            $update->assertStatus(200);
            $update->assertJson(['message' => "Order Deleted!"]);
        }
    [...]

Running the tests

After you are done writing the tests, run it with the following command on your terminal:

    $ ./vendor/bin/phpunit

Tests passing screenshot

Note: On a Windows machine, Your result will be slightly different. You will see an error relating to the testUploadImage test case. This is due to a Windows only permissions issue. If you have a way to fix this error, I will love to get a pull request from you.

Conclusion

We have examined how to write tests for applications and what should be tested. We examined how to set up our development environment for testing our application so data is not compromised. We wrote tests for a sample application to see how testing works. We looked at how to use different assertions to ensure our application returns the right data

There are still different kinds of tests we did not consider. These tests become necessary with increasing complexity of our application. At the basic level, what we have looked at would ensure our application works fine.

Feel free to change the application to return data differently to see if the tests would still pass.

The source code to the application in this article is available on GitHub.