If you’re like me, you really appreciate a test automation step as part of your pull request (PR) CI for that added confidence before merging code. I want to show you how to add Playwright tests to your PRs and how to tie it all together with a GitHub Actions CI workflow. By Liran Tal.
import { test, expect } from '@playwright/test';
test('page should have title of "Dogs security blog"', async ({ page }) => {
await page.goto('http://localhost:3000/');
const title = await page.title();
expect(title).toBe(“Dogs security blog”);
});
If you’ve never come across Playwright before, the Playwright test automation framework has had its first release in 2017, but has recently grown in popularity as another one of Microsoft’s developer tooling (in addition to Visual Studio Code and others). The Playwright test automation framework is a great way to easily write end-to-end (E2E) tests and also target cross-browser compatibility. I’ve used both Selenium and Cypress in the past, and if you’ve had any similar experience, then Playwright will surely remind you of the latter. It’s easy to get started, easy to write tests, and has built-in measures to ensure tests aren’t flaky.
In this article you will learn:
- The basics of how to write end-to-end tests with Playwright
- How to run Playwright tests in your GitHub Actions CI
- How to run Playwright tests for your deployed Netlify preview URLs
- How to preserve Playwright debug traces and make them available as build artifacts in GitHub Actions CI
Unlike Cypress, another test automation tool, which injects itself as a library to the web page DOM as its primary architecture to control the browser, Playwright uses native browser APIs to control the automation. Very interesting!
[Read More]