Email is one of the most important tools organizations have to connect with their users and prospective customers. Whether it’s a marketing campaign, account notification, or status update, consumers now expect clear communication from brands ranging from financial institutions to their favorite jeans shop. Yet testing emails as it relates to the overall web experience has been an ongoing challenge for quality professionals. The growing complexity of email scenarios - especially when APIs, mobile, and PDFs are factored in - limits the number of testers with the coding skills to execute the full range of tests needed. 

Luckily, low-code test automation platforms are bridging the gap between testers with expertise in testing from the user perspective and the complexity of testing email. Today, we take a look at what these tests look like in the mabl application.

Email Testing in mabl

As a fully low-code solution, mabl enables testers to address both simple or complex scenarios. In this hypothetical test case, we examine the use of API and Javascript steps to manage sending an email via a third party API as well as using a JS variable step to construct an attached PDF and other files as B64 strings. 

Our Real-world Scenario

A user’s application is used to filter and flag various emails coming into their  inbox. The application uses a set of rules to decide if an email should be flagged and blocked, in which case it’s placed in quarantine for users to review within the application. In order to test this functionality, it’s essential that our test is able to send an email from a predefined email address, which we can then flag within the application to block and verify its status as quarantined. 

The mabl Mailbox feature allows us to validate the email’s contents by generating a unique email address that can receive emails from your application within the automated test. This will allow us to interact with and assert against all received emails using the mabl application. We’ll also leverage our API and Javascript steps to handle the construction and sending of our spam email to our application.

The Testing Process

First, we used the SendGrid API to send the test email, which we defined as an API step within our application. Since our organization routinely sends email attachments, we also need a way to attach a file for the JSON payload of our API call to SendGrid. The file needs to be in base64 format, we’ll use an outside tool to convert the attachment from a standard PDF to a base64 string. 

Storing our base64 string as a JS variable

Once we have our base64 string we can declare it as a Javascript variable. Though this is easily done using a standard variable with a string pattern, the Javascript editor improves our ability to edit this variable later on if needed. Now we can reference this variable within the JSON payload of our API step and include both a content-type:application/JSON header as well as set the authentication method to a bearer token holding the API key generated by SendGrid.

Creating an API step with endpoint to SendGrid

{   "personalizations": [     {       "to": [         {           "email": "",           "name": "John Doe"         }       ],       "dynamic_template_data": {         "verb": "",         "adjective": "",         "noun": "",         "currentDayofWeek": ""       },       "subject": "Hello, World!"     }   ],   "from": {     "email": "andrewh@mabl.com",     "name": "John Doe"   },   "reply_to": {     "email": "andrewh@mabl.com",     "name": "John Doe"   }, "attachments": [       {          "content": "",          "type": "application/pdf",          "filename": "mypdffile.pdf"       }    ],   "template_id": "d-81e0d440d59a490b94c687dd7567cde0" }

With our file generated in the correct format, and the API step constructed, we can begin sending emails to our mabl-created email address, which is configured to filter our flagged email address.. Since all of the data used to construct the email can be stored as variables to configure the JSON payload of the API step, we’re able use these variables to locate, identify, and validate the correct status of our newly sent email within the quarantined section of the application.

Test steps in the mabl application

Replicable, Accessible Email Testing

Using a traditional test automation framework, this process we just outlined would’ve been difficult to execute without programming know-how, making it hard to scale email and API testing at the rate needed by most organizations. As you can see, each step of the email testing process is tracked within the mabl application making it easy for anyone, even those with little to no coding experience, to replicate this test with minimal effort. 

Interested in trying email testing for yourself? Register for mabl’s two week free trial