Playwright and Github Actions

Description

In this video, I show how I use Playwright with GitHub Actions to run browser tests automatically in CI. I focus on a practical setup that helps catch UI regressions, broken user flows, and environment-specific issues before code gets merged. I walk through how Playwright fits into a modern pipeline, how GitHub Actions can trigger test runs on push and pull request events, and how I structure the workflow so test execution stays reliable and easy to maintain. If you want an automated browser testing setup that runs consistently in your repository without extra manual steps, this is the approach I use. A specific technical use case I cover is validating a login and checkout flow for a web app directly in CI. For example, when a pull request changes frontend routing, authentication logic, or form validation, Playwright can open the app, sign in with a test account, navigate through a purchase path, verify expected UI states, and fail the workflow if something breaks. This is especially useful for teams that want fast feedback on critical user journeys before deployment. I also show the core pieces needed to make this work smoothly: - installing Playwright in the project - configuring browser test execution - creating a GitHub Actions workflow - running tests in a repeatable CI environment - using test results to improve confidence in releases Example Playwright test: ```js import { test, expect } from '@playwright/test'; test('user can log in and see dashboard', async ({ page }) = { await page.goto('https://example.com/login'); await page.getByLabel('Email').fill('testuser@example.com'); await page.getByLabel('Password').fill('supersecret'); await page.getByRole('button', { name: 'Sign in' }).click(); await expect(page).toHaveURL(/dashboard/); await expect(page.getByRole('heading', { name: 'Dashboard' })).toBeVisible(); }); ``` Example Playwright config: ```js import { defineConfig, devices } from '@playwright/test'; export default defineConfig({ testDir: './tests', retries: 2, use: { baseURL: 'http://127.0.0.1:3000', headless: true, trace: 'on-first-retry', }, projects: [ { name: 'chromium', use: { ...devices['Desktop Chrome'] }, }, ], }); ``` Example GitHub Actions workflow: ```yaml name: playwright-tests on: push: branches: [main] pull_request: branches: [main] jobs: test: runs-on: ubuntu-latest steps: - name: Checkout repository uses: actions/checkout@v4 - name: Setup Node.js uses: actions/setup-node@v4 with: node-version: 20 - name: Install dependencies run: npm ci - name: Install Playwright browsers run: npx playwright install --with-deps - name: Run tests run: npx playwright test ``` This setup is useful when I want every pull request to prove that essential browser flows still work. Instead of relying only on unit tests, I can validate the actual rendered app in a browser and use GitHub Actions as the gate before merging. That makes it easier to detect real integration issues such as missing elements, broken selectors, JavaScript errors affecting navigation, or unexpected authentication failures. If you are working on a frontend app, full-stack project, SaaS dashboard, internal admin panel, or ecommerce site, this workflow gives a clean foundation for browser-based quality checks in CI with Playwright and GitHub Actions. #playwright #githubactions #automationtesting #e2etesting #ci #javascript #webtesting