Test email workflows

With Scriptless Web, you can easily create steps for testing email services. This is helpful if your application includes options that involve sending emails, such as user registration, password reset, online purchase, or mailing list subscription.

In all of these cases, you want to be able to validate if the email your app sends out is received by customers, open it in a browser to verify content or actions, and possibly check the number of emails sent. If the email includes a one-time password (OTP) or other short content, you may also want to push the email content to context so that you can reuse it elsewhere in your test.

Important: Customers must allow-list the organization and project emails in their application.

Email address format

When testing email workflows, you must use an email address that conforms to one of the following formats:

  • ses-<region>+organization-<organization_id>@perforce.com

  • ses-<region>+project-<project_id>@perforce.com

  • ses-<region>+execution-[[RUN_ID]]@perforce.com

where:

  • region is the location of the data center, which can be us, eu, or aus.

  • organization_id and project_id are global variables. You can retrieve the respective value from the Global Variables view to hard-code it or use a global variable.

  • [[RUN_ID]] is global environment variable. Using the run ID, also referred to as execution ID, if essential in scenarios where you cannot use the same email address twice, for example when registering a new user.

Example: ses-us+organization-1234567@perforce.com

Email test steps

The following table describes the test steps, or elements, available to test email workflows.

Email Service element

Description

Wait for an email

Lets you define a timeout for receiving an email, in milliseconds. The step fails if Scriptless Web does not receive the email in the specified amount of time.

Open email in the browser

Opens the email in the specified browser. For example, when you sign up for a distribution list, you will want to verify that you got an email validating the request. In this case, the email should arrive at the time of the action, and you might want to validate the content by opening it in the browser.

Consider distributing emails in HTML format.

If needed, you can filter the email by From, Subject, or To line. This is helpful if the system receives several emails at once because multiple tests using the same email address are running at the same time.

When the email displays in the browser, you can then create additional test steps using the quick action toolbar (provided the email is in HTML format).

Push email content to Context

Makes the email content available for use in later test steps. This is helpful if the email content is short, such as a one-time password (OTP). If the email includes more text, you can use the disk icon on the quick action toolbar to push a selected value to context. See also Use a context variable as data input.

Pushing the content to context requires you to provide the context as a variable name, for example emailContent, so that you can refer to it later.

Push email count to Context

Checks the number of emails that have been sent by the website to the specified email address. This is helpful if you want to make sure that:

  • Only one email is sent.

  • The number of emails sent does not exceed a certain amount.

  • Emails are sent or are no longer sent during a specific timeframe.

Pushing the email count to context requires you to provide the context as a variable name, for example emailCount, so that you can refer to it later.

You can view the status of context variables during execution.

Sample use case

Let's assume your application supports subscribing to or unsubscribing from a distribution list. In this case, you want to verify the following by running two distinct tests:

  • An email validating the request has been sent and received. The email arrives at the time of action (the time you finish subscribing or unsubscribing to the list) and includes specific content.

  • Email delivery has started or stopped. To verify this, you run the test after a while, not immediately after subscribing or unsubscribing. In this case, you do not care about the email content. In fact, the content of a random email sent through a distribution list may be difficult to verify anyway.

The following video demonstrates the subscription to a free trial of Salesforce. It shows how you implement the following steps:

  1. Provide your email address as part of the registration process.

  2. Complete the registration.

  3. Wait for an email.

  4. Verify the email content by opening it in the designated browser.