End-to-End Test Microsoft 365 Solutions with Playwright

In the past, I have written a couple of articles about end-to-end (E2E) testing your SharePoint/Microsoft Teams solutions with Cypress, Puppeteer, and Playwright. I was a big fan of Cypress, but I must admit that Playwright caught up and became my favorite tool for E2E testing.

For me, the most significant advantage of Cypress was the visual UI for running your tests, but the main disadvantage was its use of an iframe, which caused issues for testing SharePoint and Microsoft Teams. In these other articles, I shared how you could overcome these issues, but a couple of versions ago, Playwright added its UI mode, which is very similar to the Cypress UI but without the iframe issues. That, for me, was the main reason to switch to Playwright.

Show image

In this article, I will show you how to get started with Playwright and how to test your Microsoft 365 solutions with it.

Getting started

To get you started, I have created a GitHub repository, which can be used as a template and contains the following:

• Default Playwright test configuration
• Login script for Microsoft 365
• Sample test for a SharePoint page
• GitHub Actions workflow to run your tests

Authentication

To be able to run your tests for any of your Microsoft 365 solutions, you first need to authenticate. The easiest way in Playwright is to authenticate before running your tests. It is to use the storageState functionality. This storageState allows you to store the cookies and local storage of your browser session into a file that can be reused for your tests.

For the Microsoft 365 authentication, a login.setup.ts file has been created with the following steps:

1
import { test as setup } from "@playwright/test";
2
import { AuthFile } from "../constants/AuthFile";
3

4
/**
5
 * Login to Microsoft 365
6
 * More info: https://playwright.dev/docs/auth
7
 */
8
setup("authenticate", async ({ page }) => {
9
  await page.goto(process.env.PAGE_URL || "");
10

11
  const emailInput = page.locator("input[type=email]");
12
  await emailInput.waitFor();
13
  await emailInput.click();
14
  await emailInput.fill(process.env.USERNAME || "");
15

16
  await page.getByRole("button", { name: "Next" }).click();
17

18
  const passwordInput = page.locator("input[type=password]");
19
  await passwordInput.waitFor();
20
  await passwordInput.click();
21
  await passwordInput.fill(process.env.PASSWORD || "");
22

23
  await page.locator("input[type=submit][value='Sign in']").click();
24
  await page.locator("input[type=submit][value='Yes']").click();
25
  await page.waitForURL(process.env.PAGE_URL || "");
26

27
  await page.context().storageState({ path: AuthFile });
28
});

The login has been added as a dependency for the other tests, meaning that when you run a test, it authenticates, stores the state in the playwright/.auth/user.json file, and then runs the test.

You can check this out in the playwright.config.ts file:

1
export default defineConfig({
2
  ...
3
  projects: [
4
    {
5
      name: "setup",
6
      testMatch: /login\.setup.ts/,
7
    },
8
    {
9
      name: "chromium",
10
      use: {
11
        ...devices["Desktop Chrome"],
12
        viewport: {
13
          width: 2560,
14
          height: 1440,
15
        },
16
        storageState: AuthFile, // Using the auth (storage state) file
17
      },
18
      dependencies: ["setup"], // Setup will run first
19
    },
20
  ],
21
});

Writing some tests

With the login configuration in place, you only need to write some tests.

Here is an example:

1
import { test, expect, Page } from "@playwright/test";
2

3
test.describe("Page load", () => {
4
  let page: Page;
5

6
  test.beforeAll(async ({ browser }) => {
7
    // Open a new page to be reused between tests
8
    page = await browser.newPage();
9
    await page.goto(process.env.PAGE_URL || "", {
10
      waitUntil: "domcontentloaded",
11
    });
12
  });
13

14
  test.afterAll(async () => {
15
    await page.close();
16
  });
17

18
  test("Check site header title", async () => {
19
    const header = page.locator("[data-automationid='SiteHeaderTitle'] a");
20
    await header.waitFor();
21

22
    await expect(header).toHaveText("Communication site");
23
  });
24

25
  test("Check screenshot", async () => {
26
    await expect(page).toHaveScreenshot();
27
  });
28
});

In the above test, I used the logic to reuse a single page between all your tests. With this logic, the page will not be closed between each test; instead, it gets reused. It will speed up your tests SharePoint and MS Teams can be slow to load on the first time.

Out-of-the-box visual comparisons

Another great feature of the Playwright’s testing library is that it includes visual comparisons. This functionality allows you to take screenshots of your pages and compare them with previous versions. These comparisons are great for detecting visual regressions between your versions/code changes.

The result of such a visual comparison can be seen in the following screenshot:

Show image

To add a visual comparison to your test, all you need is the following code:

1
test("Check screenshot", async () => {
2
  await expect(page).toHaveScreenshot();
3
});

Conclusion

Playwright is an excellent tool for E2E testing your Microsoft 365 solutions. It is easy to get started with and has many great features out-of-the-box. To learn more about Playwright, check out their documentation.

Updates

2024-07-24

The Playwright M365 starter template can now be used in combination with MFA-enabled accounts. For more information check the Automating Microsoft 365 login with multi-factor authentication in Playwright tests article.