Laravel Email Testing: Mailtrap vs. Other Options

Building an example email app in Laravel

We assume that you already have a Laravel app that you want to use to try email testing capability. Launch it now, open the terminal and enter the following:

This will create a new mailable class in app/Mail directory. If you haven’t created one before, it will also set up the directory.

Now we can go ahead and build our test message:

To spice it up a bit, let’s use a good-looking template. For that, we can use Laravel’s templating engine, Blade. 

Templates represent views in Laravel, so keep the template file in the resources/views/mails directory. Then, we’ll create a ‘mails’ directory with a Blade template file ‘exmpl.blade.php’ inside. 

@component('mail::message')

Hello **{{$name}}**, {{-- use double space for line break --}}

Thank you for choosing Mailtrap!

Click below to start working right now

@component('mail::button', ['url' => $link])

Go to your inbox

@endcomponent

Sincerely,

Mailtrap team.

@endcomponent

If you’re not sure how exactly this works or want to customize a message even further, please refer to the excellent Laravel Docs for more details. Be sure to also check out our articles on sending emails in Laravel and Laravel Email Queues for more on the topic.

Testing emails in Laravel

Now, let’s try testing our message with some different available methods. If you haven’t yet, make sure you’ve configured a driver for email sending. 

Using Tinker to validate individual emails

A super-simple approach to email testing is with Laravel’s built-in utility known as Tinker. Tinker is a REPL (read-eval-print loop) tool. It takes a single input (for example, a request to send an email), evaluates it, and immediately returns a detailed response afterward. You can leverage the tinker functionality for Laravel and any other PHP framework with Tinkerwell, the code runner that allows you to quickly test out any PHP code in the context of your application.

It’s really handy if you set up an integration with an ESP and need to test its efficacy. In our case, the delivery will be successful or we’ll commit one of many possible errors. These could be related to the email configuration (missing ‘From’ address, etc.) or sending errors. You may, for example, get a response about an unsuccessful authentication, failed connection, or an account that needs activation, to name a few.

To run Tinker, launch the terminal and type in the following:

Then, run the following sample code:

If everything works out, you’ll see an not-very-descriptive ‘null’ response:

If you forgot to introduce yourself (skipped the ‘From’ field), you’ll get the following error:

If the SMTP authentication fails, you’ll see the following:

And if you got creative and wanted to send your test emails to hey@hi@halo@mailtrap@io, you’re likely to encounter the following error:

Mocking emails in automated tests

Since the 5.3 release of Laravel (Aug ‘16), built-in functionalities allow for mocking certain elements of applications in automated tests. This way, you can test their performance without actually executing them. As you can imagine, it’s particularly useful for emails.

Laravel provides helpers for mocking events, facades, and other jobs so that you don’t have to process complex Mockery method calls. However, if you want to play with Mockery or PHPUnit, for example, you can do that, as well.

For emails, there’s a dedicated fake method in the Mail class that prevents emails from being sent but lets you test the sending capability. After the respective code is executed, you can call various assertions to check if an email was sent successfully.

If an assertion fails, you’ll receive an error with a possible cause, similar to what Tinker would return.

To create a test for your mailer, run the following command in the project directory:

This will generate a file called ‘MailerTest.php’ in the ‘tests/Unit’ folder of your project.

Now, modify the generated file to add some tests for your mailer:

Now, run your test with the following command:

If your code works correctly, you’ll see the following result:

If something has gone wrong, like if your code didn’t set the ‘from’ field correctly, the test run will fail:

When in doubt, refer to the official Mocking documentation.

Keep in mind that this will only work with Laravel 5.3 and newer. If you still use 5.1 or 5.2 where Mail::fake() is not available, you can try a workaround. With these versions, the shouldReceive method returns an instance of Mockery mock so you can still mock the calls to the facade with the following:

Mailtrap

A much more robust alternative to the other two is Mailtrap. In case you’re not familiar with it, it serves as a “fake SMTP,” helping you isolate the testing environment from production so that test emails never end up in your users’ inbox. Watch this video to find out more!

Mailtrap not only lets you verify whether emails are sent, but it also captures them for easy previewing and debugging. You can quickly fix any visual errors, spot HTML/CSS issues, check the spam scores of emails, click-through links, and more.

Mailtrap is particularly helpful when you have complex sequences of emails to test. You can go through entire workflows and try different edge cases. One by one, the respective emails will land in your Mailtrap inbox. And if they don’t, you’ll know precisely where the problem lies.

Mailtrap is also great for teams. With the auto-forwarding feature, a manager or a client can test any staging workflows just as they would on production. They can, for example, click through an order confirmation process and get the respective emails delivered right into their inbox. On top of that, a copy of each email goes to your Mailtrap inbox for easy inspection.

There’s a lot more that only Mailtrap can do. If you haven’t yet, get an account right away, and let’s see how it works with Laravel.

How to set up Mailtrap for email testing in Laravel

Mailtrap is Laravel’s default SMTP server, so it’s very easy to integrate with. Log into your account, click on Demo Inbox, and pick ‘Laravel’ from the drop-down list of integrations. You’ll see two, ready-to-use configurations with your credentials. To integrate, follow the instructions. 

A sample configuration that you would insert into .env file of your root directory would look as follows:

Of course, feel free to insert your own email address and name into the last two lines of code.

Now, let’s send some emails that will then land in our Mailtrap inbox. For the following example to work, you’ll need to be on the 5.8 release of Laravel (or newer), so make sure you upgrade if necessary before getting started.

Once we have the configuration done, let’s finally send an email. Make sure you’ve specified the route in routes/web.php file.

Now, start the application and access/send-mail path in your browser. This will send a test email. Shortly after, you’ll see the following output in your Mailtrap inbox:

Alternatively, you can integrate your Laravel app with Mailtrap via Mailtrap API and automate your email testing process. For details, refer to the API documentation.

Wrapping up

Each of the tools we described can be helpful in some way. Tinker is really handy if you’ve already set up an integration with an ESP and wish to quickly try it out. The error messages are quite descriptive and can help you pinpoint the errors you may have missed before. Mocking also offers similar functionality, but is more suitable for automated tests.

Still, there’s a lot more to email testing than all that. If you want to see precisely what your platform sends, quickly debug errors, and report with ease on your progress, you need a dedicated environment.

There are plenty of reasons why thousands of Laravel developers have trusted Mailtrap. If you haven’t yet, get an account right away and see how easy email testing can be.

That's it! I hope you enjoyed reading our guide on testing emails in Laravel that was originally published on Mailtrap Blog by Piotr Malek.