When talking about automated tests or unit tests in any programming language, there are two groups of people:
- Those who don’t write automated tests and think they’re a waste of time
- Those who do write tests and then can’t imagine their work without them
So, with this article, I will try to convince the former camp to look at the other side and see the benefits, and see how easy it is to start with automated testing in Laravel.
First, let’s talk about the “why” and then I’ll show a few very basic examples of the “how”.
Why You Need Automated Tests
Automated tests are not complicated: they just run parts of your code for you and report any errors. That’s the most simple way to describe them. Imagine that you’re launching a new feature in your app, and then a personal robot assistant would go and manually test the new functionality for you, also testing if the new code didn’t break anything from the old features.
That’s the main benefit: re-testing all the features automatically. And it may seem like extra work, but if you don’t tell that “robot” to do it, then you should do it manually yourself, right? Or do you just launch the new features without too much testing, hoping that the users would report the bugs? I call that method sarcastically “fingers-crossed-driven development”.
With every new feature of your app, automated tests pay off more and more.
- Feature 1: saves X minutes of testing manually
- Feature 2: saves 2X minutes – for feature 2 and feature 1 again
- Feature 3: saves 3X minutes…
- etc.
You get the idea. Imagine your application in a year or two, with new developers on the team who wouldn’t even know how that “Feature 1” works or how to reproduce it for testing. So, your future self will thank you massively for writing the automated tests.
Of course, if you think that your project is a very short-term one and you don’t care that much about its future… Nah, I believe in your good intentions, so let me show you how it’s easy to start testing.
Our First Automated Tests
To run the first automated test in Laravel, you don’t need to write any code. Yup, you’ve read that right. Everything is already configured and prepared in the default Laravel installation, including the first real basic example.
You can try to install a Laravel project and immediately run the first tests:
1laravel new project
2cd project
3php artisan test
This should be the result in your console:
1 PASS Tests\Unit\ExampleTest
2✓ that true is true
3
4 PASS Tests\Feature\ExampleTest
5✓ the application returns a successful response
6
7Tests: 2 passed
8Time: 0.10s
If we take a look at the default Laravel /tests folder, we have two files.
tests/Feature/ExampleTest.php:
1class ExampleTest extends TestCase
2{
3 public function test_the_application_returns_a_successful_response()
4 {
5 $response = $this->get('/');
6
7 $response->assertStatus(200);
8 }
9}
There’s no need to know any syntax, to understand what is happening here: loading the homepage and checking if the HTTP status code is “200 OK”.
Also notice how the method name test_the_application_returns_a_successful_response() becomes readable text when viewing the test results, just replacing the underscore symbol with a space.
tests/Unit/ExampleTest.php:
1class ExampleTest extends TestCase
2{
3 public function test_that_true_is_true()
4 {
5 $this->assertTrue(true);
6 }
7}
This looks a bit pointless, checking that true is true? We’ll talk about unit tests specifically, a bit later. For now, you need to understand what is generally happening in every test.
- Each test file in the
tests/ folder is a PHP Class extending the TestCase of PHPUnit
- Inside of each class, you may create multiple methods, usually one method for one situation to be tested
- Inside of each method, there are three actions: preparation of the situation, then action, and then checking (asserting) if the result is as expected
Structurally, that’s all you need to know, everything else depends on the exact things you want to test.
To generate an empty test class, you just run this command:
1php artisan make:test HomepageTest
It would generate the file tests/Feature/HomepageTest.php:
1class HomepageTest extends TestCase
2{
3 // Replace this method with your own ones
4 public function test_example()
5 {
6 $response = $this->get('/');
7
8 $response->assertStatus(200);
9 }
10}
What If Tests Fail?
Let me show you what happens if the test assertions don’t return the expected result.
Let’s edit the example tests to this:
1class ExampleTest extends TestCase
2{
3 public function test_the_application_returns_a_successful_response()
4 {
5 $response = $this->get('/non-existing-url');
6
7 $response->assertStatus(200);
8 }
9}
10
11
12class ExampleTest extends TestCase
13{
14 public function test_that_true_is_false()
15 {
16 $this->assertTrue(false);
17 }
18}
And now, if we run php artisan test again:
1
2 FAIL Tests\Unit\ExampleTest
3⨯ that true is true
4
5 FAIL Tests\Feature\ExampleTest
6⨯ the application returns a successful response
7
8---
9
10• Tests\Unit\ExampleTest > that true is true
11Failed asserting that false is true.
12
13at tests/Unit/ExampleTest.php:16
14 12▕ * @return void
15 13▕ */
16 14▕ public function test_that_true_is_true()
17 15▕ {
18➜ 16▕ $this->assertTrue(false);
19 17▕ }
20 18▕ }
21 19▕
22
23• Tests\Feature\ExampleTest > the application returns a successful response
24Expected response status code [200] but received 404.
25Failed asserting that 200 is identical to 404.
26
27at tests/Feature/ExampleTest.php:19
28 15▕ public function test_the_application_returns_a_successful_response()
29 16▕ {
30 17▕ $response = $this->get('/non-existing-url');
31 18▕
32➜ 19▕ $response->assertStatus(200);
33 20▕ }
34 21▕ }
35 22▕
36
37
38Tests: 2 failed
39Time: 0.11s
As you can see, there are two statements marked as FAIL, with explanations below and arrows to the exact test line that failed the assertion. So this is how the errors are shown. Convenient, isn’t it?
Simple Real-Life Example: Registration Form
Let’s get more practical and look at a real-life example. Imagine that you have a form, and you need to test various cases: check if it fails if filled with invalid data, check if it succeeds with the correct input, etc.
Did you know that the official Laravel Breeze starter kit comes with the feature tests inside? So, let’s take a look at a few examples from there:
tests/Feature/RegistrationTest.php
1use App\Providers\RouteServiceProvider;
2use Illuminate\Foundation\Testing\RefreshDatabase;
3use Tests\TestCase;
4
5class RegistrationTest extends TestCase
6{
7 use RefreshDatabase;
8
9 public function test_registration_screen_can_be_rendered()
10 {
11 $response = $this->get('/register');
12
13 $response->assertStatus(200);
14 }
15
16 public function test_new_users_can_register()
17 {
18 $response = $this->post('/register', [
19 'name' => 'Test User',
20 'email' => 'test@example.com',
21 'password' => 'password',
22 'password_confirmation' => 'password',
23 ]);
24
25 $this->assertAuthenticated();
26 $response->assertRedirect(RouteServiceProvider::HOME);
27 }
28}
Here we have two tests in one class, as they are both related to the registration form: one is checking if the form is loaded correctly, and another one checks if the submission works well.
We get familiar with two other methods of checking the result, two more assertions: $this->assertAuthenticated() and $response->assertRedirect(). You can check all the available assertions in the official documentation of PHPUnit and Laravel Response. Keep in mind that some general assertions happen on $this object, while others check the specific $response from the route call.
Another important thing is the use RefreshDatabase; statement, with the trait, included above the class. It is needed when your test actions may affect the database, like in this example, registration adds a new entry in the users database table. For that, you would need to create a separate testing database that would be refreshed with php artisan migrate:fresh, every time the tests are executed.
You have two options: physically create a separate database, or use an in-memory SQLite database. It is both configured in the file phpunit.xml that comes by default with Laravel. Specifically, you need this part:
1<php>
2 <env name="APP_ENV" value="testing"/>
3 <env name="BCRYPT_ROUNDS" value="4"/>
4 <env name="CACHE_DRIVER" value="array"/>
5 <!-- <env name="DB_CONNECTION" value="sqlite"/> -->
6 <!-- <env name="DB_DATABASE" value=":memory:"/> -->
7 <env name="MAIL_MAILER" value="array"/>
8 <env name="QUEUE_CONNECTION" value="sync"/>
9 <env name="SESSION_DRIVER" value="array"/>
10 <env name="TELESCOPE_ENABLED" value="false"/>
11</php>
See the DB_CONNECTION and DB_DATABASE which are commented out? If you have SQLite on your server, the easiest action is to just uncomment those lines, and your tests will run on that in-memory database.
In this test, we assert that the user is authenticated successfully and is redirected to the correct homepage, but we can also test the actual data in the database.
In addition to this code:
1$this->assertAuthenticated();
2$response->assertRedirect(RouteServiceProvider::HOME);
We can also use Database Testing assertions and do something like this:
1$this->assertDatabaseCount('users', 1);
2
3// Or...
4$this->assertDatabaseHas('users', [
5 'email' => 'test@example.com',
6]);
Another Real-Life Example: Login Form
Let’s take a look at one more test from Laravel Breeze.
tests/Feature/AuthenticationTest.php:
1class AuthenticationTest extends TestCase
2{
3 use RefreshDatabase;
4
5 public function test_login_screen_can_be_rendered()
6 {
7 $response = $this->get('/login');
8
9 $response->assertStatus(200);
10 }
11
12 public function test_users_can_authenticate_using_the_login_screen()
13 {
14 $user = User::factory()->create();
15
16 $response = $this->post('/login', [
17 'email' => $user->email,
18 'password' => 'password',
19 ]);
20
21 $this->assertAuthenticated();
22 $response->assertRedirect(RouteServiceProvider::HOME);
23 }
24
25 public function test_users_can_not_authenticate_with_invalid_password()
26 {
27 $user = User::factory()->create();
28
29 $this->post('/login', [
30 'email' => $user->email,
31 'password' => 'wrong-password',
32 ]);
33
34 $this->assertGuest();
35 }
36}
This is about the login form. The logic is similar to the registration, right? But three methods instead of two, so this is an example of testing both good and bad scenarios. So, the common logic is that you should test both cases: when things go well and when they fail.
Also, what you see in this test is the usage of Database Factories: Laravel creates a fake user (again, on your refreshed testing database) and then tries to log in, with correct or incorrect credentials.
Again, Laravel generates the default factory with fake data for the User model, out of the box.
database/factories/UserFactory.php:
1class UserFactory extends Factory
2{
3 public function definition()
4 {
5 return [
6 'name' => $this->faker->name(),
7 'email' => $this->faker->unique()->safeEmail(),
8 'email_verified_at' => now(),
9 'password' => '$2y$10$92IXUNpkjO0rOQ5byMi.Ye4oKoEa3Ro9llC/.og/at2.uheWG/igi', // password
10 'remember_token' => Str::random(10),
11 ];
12 }
13}
See, how many things are prepared by Laravel itself, so it would be easy for us to start testing?
So, if we run php artisan test after installing Laravel Breeze, we should see something like this:
1 PASS Tests\Unit\ExampleTest
2✓ that true is true
3
4 PASS Tests\Feature\Auth\AuthenticationTest
5✓ login screen can be rendered
6✓ users can authenticate using the login screen
7✓ users can not authenticate with invalid password
8
9 PASS Tests\Feature\Auth\EmailVerificationTest
10✓ email verification screen can be rendered
11✓ email can be verified
12✓ email is not verified with invalid hash
13
14 PASS Tests\Feature\Auth\PasswordConfirmationTest
15✓ confirm password screen can be rendered
16✓ password can be confirmed
17✓ password is not confirmed with invalid password
18
19 PASS Tests\Feature\Auth\PasswordResetTest
20✓ reset password link screen can be rendered
21✓ reset password link can be requested
22✓ reset password screen can be rendered
23✓ password can be reset with valid token
24
25 PASS Tests\Feature\Auth\RegistrationTest
26✓ registration screen can be rendered
27✓ new users can register
28
29 PASS Tests\Feature\ExampleTest
30✓ the application returns a successful response
31
32Tests: 17 passed
33Time: 0.61s
Feature Tests VS Unit Tests VS Others
You’ve seen the tests/Feature and tests/Unit subfolders. What is the difference between them? The answer is a little “philosophical”.
Globally, outside of Laravel/PHP ecosystem, there are different kinds of automated tests. You can find such terms as:
- Unit tests
- Feature tests
- Integration tests
- Functional tests
- End-to-end tests
- Acceptance tests
- Smoke tests
- etc.
It sounds complicated, and the actual differences between those test types sometimes are blurred. That’s why Laravel simplified all those confusing terms and grouped them into two: unit/feature.
In simple words, feature tests try to run the actual features of your applications: get the URL, call the API, mimic the exact behavior like filling in the form. Feature tests usually execute the same or similar thing as any project user would do, manually, in real life.
Unit tests have two meanings. Generally, you may find that any automated tests are called “unit tests”, and the whole process may be called “unit testing”. But in the context of feature vs unit, this process is about testing a specific non-public unit of your code, in isolation. For example, you have some Laravel class with a method that calculates something, like the total price of the order with parameters. So, your unit test would assert if the correct results are returned by that method (unit of code), with different parameters.
To generate a unit test, you need to add a flag:
1php artisan make:test OrderPriceTest --unit
The generated code is the same as the default unit test from Laravel:
1class OrderPriceTest extends TestCase
2{
3 public function test_example()
4 {
5 $this->assertTrue(true);
6 }
7}
As you can see, there’s no RefreshDatabase, and that’s one of the most common definitions of a unit test: it doesn’t touch the database, it works like a “black box”, in isolation from the running application.
Trying to mimic the example I mentioned earlier, let’s imagine we have a service class OrderPrice.
app/Services/OrderPriceService.php:
1class OrderPriceService
2{
3 public function calculatePrice($productId, $quantity, $tax = 0.0)
4 {
5 // Some kind of calculation logic
6 }
7}
Then, the unit test could look something like this:
1class OrderPriceTest extends TestCase
2{
3 public function test_single_product_no_taxes()
4 {
5 $product = Product::factory()->create(); // generate a fake product
6 $price = (new OrderPriceService())->calculatePrice($product->id, 1);
7 $this->assertEquals(1, $price);
8 }
9
10 public function test_single_product_with_taxes()
11 {
12 $price = (new OrderPriceService())->calculatePrice($product->id, 1, 20);
13 $this->assertEquals(1.2, $price);
14 }
15
16 // More cases with more parameters
17}
In my personal experience with Laravel projects, the absolute majority of the tests are Feature tests, not Unit tests. First, you need to test if your application works, the way how real people would use it.
Next, if you have special calculations or logic that you can define as a unit, with parameters, you may create unit tests specifically for that.
Sometimes, writing tests requires changing the code itself, and refactoring it to be more “testable”: separating the units into special classes or methods.
When/How To Run Tests?
What is the actual usage of that php artisan test, when you should run that?
There are different approaches, depending on your company workflow, but typically, you need to make sure that all tests are “green” (meaning, no errors) before you push your latest code changes to the repository.
So, you work locally on your task, and when you feel like you’ve finished, you run tests to make sure you didn’t break anything. Remember, your code may cause bugs not only in your logic but also unintentionally break some other behavior in someone else’s code written a long time ago.
If we take it a step further, it’s possible to automate a lot of things. With various CI/CD tools, you can specify your tests to be executed whenever someone pushes the changes to a specific Git branch, or before merging the code into the production branch. The easiest workflow would be to use Github Actions, I have a separate video demonstrating it.
What Should You Test?
There are various opinions on how big your so-called “test coverage” should be: should you test every operation and every possible case on every page, or just limit your work to the most important parts.
Indeed, this is where I agree with people blaming automated testing for taking more time than bringing the actual benefits. That may happen if you write tests for every single detail. That said, it may be required by your project: the main question is “what is the price of the potential error”.
In other words, you need to prioritize your testing efforts with the question “What would happen if this code fails?” If your payment system has bugs, it will directly impact the business. Then, if your roles/permissions functionality is broken, then it’s a huge security issue.
I like how Matt Stauffer phrased it during one conference: “You need to test those things first, which, if they fail, would get you fired from your job”. Of course, it’s an exaggeration, but you get the idea: test the important things first. And then other functionality, if you have time for it.
PEST: New Popular Alternative to PHPUnit
All the examples above are based on the default Laravel testing tool: PHPUnit. But over the years other tools were appearing in the ecosystem, and one of the latest popular ones is PEST. Created by the official Laravel employee Nuno Maduro, it has the goal of simplifying the syntax, making it even quicker to write the code for tests.
Under the hood, it runs on top of PHPUnit, as an additional layer, just trying to minimize some default repeating parts of PHPUnit code.
Let’s take a look at an example. Remember the default Feature test class in Laravel? I will remind you:
1namespace Tests\Feature;
2
3use Illuminate\Foundation\Testing\RefreshDatabase;
4use Tests\TestCase;
5
6class ExampleTest extends TestCase
7{
8 public function test_the_application_returns_a_successful_response()
9 {
10 $response = $this->get('/');
11
12 $response->assertStatus(200);
13 }
14}
Do you know how the same test would look with PEST?
1test('the application returns a successful response')->get('/')->assertStatus(200);
Yes, ONE line of code, and that’s it. So, the goal of PEST is to remove the overhead of:
- Creating classes and methods for everything;
- Extending TestCase;
- Putting actions on separate lines – in PEST, you can chain them.
To generate a PEST test in Laravel, you need to specify an additional flag:
1php artisan make:test HomepageTest --pest
At the time of writing this article, PEST is quite popular among Laravel developers, but it’s your personal preference whether to use this extra tool and learn its syntax, in addition to a well-known PHPUnit.
So, that’s all you need to know about the basics of automated testing. From here, it’s your choice on what tests to create and how to run them in your projects.
For more information, refer to the official Laravel docs on testing.
Cj comms open 1/6 slots (@ShiijeiKun) February 21, 2022
When one is responsible for promoting application development from Dev through the various environments such as QA, UAT, etc., through Production, it is often useful to ensure that configurations in test environments are comparable to the final production environment. This is especially true with systems where a team of DBAs manage the servers.
