Set up Outlook for tests

Test user registration and login using variables with outlook

Built-in variables solve multiple problems of testing user sign-up and logging in.

Test case: as a user, I go to the homepage and click "sign up" button. I enter my email and password. I receive a verification email. I click the link. I use previous email and password to log in.

We're going to use variables to solve a number of problems

• How to get a unique random email address

• How to receive the email with the authorization link

• How to use previously generated unique email and password in the login form

1. Prepare the email inbox

Register a new account in an email provider that supports plus aliasing or sub-addressing ex. Outlook or iCloud mail.

Important! Don't use Gmail as BugBug extension will fail in the Gmail app because of a bug caused by Chromium

Let's assume you registered such an email [e-mail]

Important tips on Outlook configuration

Your emails may be at first classified as "junk mail", but later Outlook may just put them in your inbox and organize them into a conversation. To prevent this unpredictable behavior you need to change a few switches in the Outlook settings

Add BugBug email to safe addresses to prevent junk email classification

Disable the conversation view in Outlook settings

Disable the Focused inbox

2. Record the sign-up and login without variables

Create a new test and start recording. When you're about to enter the registered email address, remember to use the plus aliasing and add a random text after the "+" symbol for example [e-mail]

We're going to replace this suffix later with a variable!

During the recording, open a new tab and access your email inbox. Use your normal email address without the +12345 part in the email log-in form.

Find the email with the authorization link.

Don't forget to check the junk email folder! To prevent that we recommend that you add BugBug email to "safe emails" in Outlook settings.

Important! Make sure you click the subject line of the email! BugBug needs to always open the most recent email, so your selector here needs to click the first email with a specific subject line, for example //SPAN[normalize-space(text())="Finish your sign-up"]

Now just click the Button with the authorization link and continue recording.

If your email doesn't have a button but just a verification link

If your verification link is shown directly as a string, this string will be different every time. BugBug will record a selector that matches exactly this string, for example //A[normalize-space(text())="https://acmecorp.com/#/activate?key=60f0ae29-542a-4418-8529-41a01bf22fcc"]

In such case, you may need to manually update your selector after the recording so that it only checks if the text contains the beginning of the verification URL, for example //*[contains(text(), "https://acmecorp.com/#/activate")

In the login form to your app, remember to again use the email address with the plus alias [e-mail]

Now finish the recording. We now need to replace the recorded texts with variables manually.

3. Replace the email sub-address with a built-in variable

If you run the test without using variables, it will fail because you will get a validation "This email already exists".

We need to have a unique email address every time we run this test.

To do this, you can use a built-in variable testRunId

In the test find all the steps that use [e-mail] and replace it with acmeautomation+{{testRunId}}@outlook.com

4. Run the test to see the results

Every time you run the test, you will see that a new unique email address is typed in the registration and login fields.

You will see a computed value in the step details.

Computed value will appear below the field after a test run