Probably, one of the most frequent issues that the web developers always face while developing and testing is sending tons of test e-mails to real users. It’s always better to have a good emulator system, allows you to create as many as e-mail accounts and use these e-mails to test your new function.
This will allow developers to work with the real data, not with something artificial or fake. For instance, to register a new user (even for the purpose of testing), you need a user’s email address where you will send a confirmation e-mail.
At the same time, using real customers’ data for testing your app can be pretty risky since test e-mails from staging environment might be sent to your clients’ e-mail inboxes. This may occur when testing the application you need, for example, to reset user’s password. As a result, the application sends the e-mail containing a particular password reset link to all customers.
All you get is that feeling of awkwardness. Or another example: your application has become a real product used by many clients, and it functions successfully. Every week you need to send notifications of different contents to different users. The challenge is to check whether the right email was sent to the right user. Since there is no point in creating hundreds of fake users and checking their e-mails, you need a better solution.
Here Are The Most Popular Solutions:
1. Set up a SMTP server in such a way that it will send messages according to a certain pattern. Your server will write your e-mail address instead of user’s one. In this case, e-mails will be sent to all developers. Its main disadvantage is that each team member gets up to hundred emails in their mailbox each time QA engineers test new application releases.
2. Use a special script to separate real users’ emails from your test email database. In this case, the main downside is that you will still need to have some fake email addresses. However, you can be sure that real users won’t get your test e-mails.
3. Use dummy SMTP servers. In this case, messages will not be sent, but stored locally. This method isn’t flawless too: the e-mails cannot be accessed by most non-developers who actually test the functionality of an app.
4. Hardcode application logic for different environments. For instance, an application will send e-mails from production servers but will forward the messages to the specific e-mail addresses other than of your domain. Although this method seems to be better than the previous three, it’s more complicated regarding implementation and support.
As you can see, it is possible to set up the testing manually and be quite sure that you won’t spam your customers with testing e-mails. However, Railsware created an alternative solution that offers the same features by default – Mailtrap.
Mailtrap is the service that provides the fake SMTP server using which you can test e-mail notifications without accidentally sending them to real customers of your application. It also allows you to view the sent e-mails, forward them to your mailbox, and share them with your team members during the pre-production stage. Since the service is hosted, you don’t have to install anything – just specify Mailtrap as a SMTP server in your pre-production environment and start testing your e-mails.
Using This Fake SMTP Server You:
- Don’t have to set up you e-mail server.
- Don’t have to clean your database from the clients’ e-mail addresses.
- Don’t have to make any special tweaks in your application code.
- Can use the real customers’ e-mail without the fear of spamming them accidentally.
- Can use it with any programming language and framework.
Is It A Free Service?
It’s a free service for a small project or team, performed by one or a few developers. If you are working on a larger project, it will cost you from $10 to $25 per month.
How Does It Work?
You need to register to get Mailtrap’s SMTP credentials which you will insert into your application’s configuration. After that, you will be able to use this service.
To start, you can visit the Mailtrap’s website and register by using your GitHub or Google account:
The registration process with a GitHub account is pretty easy. Just click on the “Authorize application” and all is set.
Once the registration is confirmed, your demo e-mail account in the Mailtrap GUI will look like this:
Setting Up Mailtrap Within The Development Environment
Next thing to do is to setup the Mailtrap server to the development (pre-production) environment.
To do that, clicking on the “Settings” icon you will see that each of the Mailtrap e-mail inboxes has its own credentials:
This credentials can be reset whenever you want. Just press the “Reset” link and all will be done immediately. Mailtrap offers several different configuration examples that you can try:
To give you a simple example, I will use “Hello” application (the Yii2 series) and then configure Mailtrap.
If you want to use its code to test Mailtrap service, just clone the GitHub repository. Find the link below.
By using Yii, you need to update SwiftMailer SMTP settings from config/web.php. The default should be like this:
Then, I substitute it with my Mailtrap settings:
Then, you need to go to localhost/hello/user/register with port 8888, or simply visit here and sign up an account again:
You will receive a confirmation e-mail from Yii, like this:
The message instantly appears in your Mailtrap e-mail inbox. This is how the confirmation e-mail looks like:
Mailtrap offers several tabs that you can choose to debug the application’s outbound email. The HTML source code is as the following:
The validation against your email:
The image below is showing to you both the spam and blacklist score of your e-mail inbox and the SMTP server:
That is how does Mailtrap works to check the content of your e-mails and markup.
By using the Mailtrap API, you can write any automated test that will help you check the content of the e-mails. For further details, please read the Mailtrap API documentation here. You can run the scripts and work with the real data of your app to verify the content automatically, and the makeup of the e-mails containing real data.
We hope this article will help you to learn more how to test your email function on your new project or website without spamming the real customers’ emails.
This is a guest post, contributed by Oleg Mishyn. If you have any question or issue about this article, let us know.