How to implement end-to-end testing for a WordPress site with Playwright?

So, you want to get serious about testing your WordPress site, and you’ve heard good things about Playwright. Excellent choice! Implementing end-to-end (E2E) testing with Playwright for a WordPress site isn’t as daunting as it might seem, and it offers incredible benefits for catching bugs before your users do. In short, you’ll be writing automated scripts that mimic how a real user interacts with your site, then running those scripts to ensure everything from logging in to submitting a form works flawlessly.

Why Playwright for WordPress?

WordPress is dynamic. Plugins, themes, and content updates happen frequently, and with each change, there’s a risk of breaking something. Manual testing is time-consuming and prone to human error. Playwright, a modern E2E testing framework from Microsoft, shines here because it:

Supports all major browsers: Chromium, Firefox, and WebKit (Safari) – testing across all of them ensures broad compatibility.
Is fast and reliable: Built for modern web applications, it’s designed to be quick and reduce flaky tests.
Has excellent developer experience: Clear APIs, comprehensive documentation, and powerful debugging tools.
Handles dynamic content well: Perfect for WordPress sites with interactive elements, AJAX, and changing content.

Let’s break down how to get this set up.

Before we dive into writing tests, we need to get our workspace ready. This involves installing Node.js, Playwright, and setting up a basic project structure.

Node.js and npm Installation

Playwright is a Node.js library, so you’ll need Node.js and its package manager (npm) installed on your system.

Check existing installation: Open your terminal or command prompt and run:

“`bash

node -v

npm -v

“`

If you see version numbers, you’re good to go.

Install if needed: If not, head over to the official Node.js website and download the LTS (Long Term Support) version. The installer will typically include npm. Follow the on-screen instructions.

Initializing Your Project

Once Node.js is ready, create a new directory for your tests and initialize a Node.js project.

Create project directory:

“`bash

mkdir wordpress-playwright-tests

cd wordpress-playwright-tests

“`

Initialize npm project:

“`bash

npm init -y

“`

This creates a package.json file, which is where npm keeps track of your project’s dependencies and scripts. The -y flag answers “yes” to all setup questions, making it quicker.

Installing Playwright

Now, let’s bring Playwright into your project.

Install Playwright locally:

“`bash

npm install @playwright/test

npx playwright install

“`

The npm install @playwright/test command downloads the Playwright test runner and libraries. The npx playwright install command downloads the necessary browser binaries (Chromium, Firefox, WebKit) that Playwright uses to run your tests. This step is crucial.

For those looking to enhance their WordPress site testing strategies, implementing end-to-end testing with Playwright can significantly improve the reliability of your web applications. To complement your testing efforts, you might find it useful to explore related topics, such as setting up email functionalities on your site. A helpful resource on this subject is an article that discusses how to send emails using CyberPanel, which can be found here. This information can be invaluable when ensuring that your end-to-end tests cover all aspects of user interactions, including email notifications.

Crafting Your First WordPress Test

With Playwright installed, it’s time to write a simple test to ensure everything is working. We’ll start with something basic: navigating to your WordPress site’s homepage and checking for a specific piece of text.

Creating Your Test File

Create a tests directory: It’s good practice to keep your tests organized.

“`bash

mkdir tests

“`

Create your first test file: Inside the tests directory, create a file named homepage.spec.js (Playwright typically looks for files ending in .spec.js, .spec.ts, .test.js, or .test.ts).

Writing the Homepage Test

Open tests/homepage.spec.js and add the following code:

“`javascript

// tests/homepage.spec.js

const { test, expect } = require(‘@playwright/test’);

// Define the base URL for your WordPress site

const WP_BASE_URL = process.env.WP_BASE_URL || ‘http://localhost:8080/’; // Replace with your actual WP URL if not running locally

test.describe(‘WordPress Homepage’, () => {

test(‘should have the correct title’, async ({ page }) => {

// Navigate to the WordPress site

await page.goto(WP_BASE_URL);

// Expect a title to contain the site’s name (adjust for your site)

await expect(page).toHaveTitle(/Your Site Title/); // Replace ‘Your Site Title’ with your actual site’s title or part of it

// Optional: Check for a visible element that confirms content loaded

await expect(page.locator(‘h1.entry-title’).first()).toBeVisible(); // Common for post titles

});

test(‘should display the main navigation menu’, async ({ page }) => {

await page.goto(WP_BASE_URL);

// Assuming your theme has a main navigation with an ID like ‘primary-menu’

await expect(page.locator(‘#primary-menu’)).toBeVisible();

// More specific: check for menu items

await expect(page.locator(‘#primary-menu li a’).first()).toBeVisible();

await expect(page.locator(‘#primary-menu li a’).nth(1)).toBeVisible();

});

“`

Understanding the Code

const { test, expect } = require('@playwright/test');: This line imports the core test and expect functions from Playwright. test is used to define test blocks, and expect is for assertions.
WP_BASE_URL: It’s good practice to define your base URL as a variable or, better yet, use an environment variable (as shown) so your tests can easily run against different environments (dev, staging, production).
test.describe('WordPress Homepage', () => { ... });: This groups related tests together, making your test reports cleaner.
test('should have the correct title', async ({ page }) => { ... });: This defines an individual test.
async ({ page }) => { ... }: The page object is automatically provided by Playwright and is your primary interface for interacting with the browser. All Playwright actions are asynchronous, hence async and await.
await page.goto(WP_BASE_URL);: Navigates the browser to your WordPress site.
await expect(page).toHaveTitle(/Your Site Title/);: This is an assertion. It checks if the page’s title matches the provided regular expression. Remember to change /Your Site Title/ to a part of your actual WordPress site’s title.
await expect(page.locator('h1.entry-title').first()).toBeVisible();: This locates an element using a CSS selector (h1.entry-title) and asserts that the first one found is visible. This is a common way to confirm that actual content has loaded.

Running Your First Test

Basic run:

“`bash

npx playwright test

“`

This command will run all tests in your tests directory. You should see a browser open, navigate to your site, and then close.

Specify a test file:

“`bash

npx playwright test tests/homepage.spec.js

“`

Run in headed mode (see the browser): For debugging, it’s often helpful to see what Playwright is doing.

“`bash

npx playwright test tests/homepage.spec.js –headed

“`

Set base URL (important!): If your WordPress site isn’t at http://localhost:8080/, you must set the WP_BASE_URL environment variable before running.

“`bash

WP_BASE_URL=’https://your-live-wp-site.com/’ npx playwright test tests/homepage.spec.js –headed

“`

or, add it to your package.json scripts:

“`json

“scripts”: {

“test”: “npx playwright test”,

“test:homepage”: “WP_BASE_URL=’https://your-live-wp-site.com/’ npx playwright test tests/homepage.spec.js”

}

“`

Then run npm run test:homepage

If everything is configured correctly, your test should pass, and you’ll see a success message in your terminal. If it fails, Playwright will give you a clear error message and potentially a screenshot.

Testing WordPress Login and Admin Functionality

One of the most critical aspects of a WordPress site is its backend. Let’s write a test to log into the admin dashboard.

Storing Credentials Securely

Never hardcode sensitive information like usernames and passwords directly in your test files. Use environment variables.

Create a .env file: In the root of your wordpress-playwright-tests directory, create a file named .env.
Add credentials:

“`

.env

WP_USERNAME=your_admin_username

WP_PASSWORD=your_admin_password

WP_BASE_URL=http://localhost:8080/ # Or your actual URL

“`

Important: Add .env to your .gitignore file to prevent it from being committed to version control!

Install dotenv: To load these variables into your Node.js process:

“`bash

npm install dotenv

“`

Load in your tests: At the very top of your test files (or a central setup file), add:

“`javascript

require(‘dotenv’).config();

“`

Now, process.env.WP_USERNAME, process.env.WP_PASSWORD, and process.env.WP_BASE_URL will be available.

Writing the Login Test

Create a new file: tests/admin-login.spec.js.

“`javascript

// tests/admin-login.spec.js

require(‘dotenv’).config(); // Load environment variables first

const { test, expect } = require(‘@playwright/test’);

const WP_BASE_URL = process.env.WP_BASE_URL;

const WP_ADMIN_USERNAME = process.env.WP_USERNAME;

const WP_ADMIN_PASSWORD = process.env.WP_PASSWORD;

test.describe(‘WordPress Admin Login’, () => {

test.beforeEach(async ({ page }) => {

// Navigate to the WordPress login page before each test in this describe block

await page.goto(${WP_BASE_URL}/wp-admin);

});

test(‘should allow a user to log in with valid credentials’, async ({ page }) => {

// Fill in the username and password fields

await page.fill(‘#user_login’, WP_ADMIN_USERNAME);

await page.fill(‘#user_pass’, WP_ADMIN_PASSWORD);

// Click the “Log In” button

await page.click(‘#wp-submit’);

// Expect to be redirected to the dashboard

await expect(page).toHaveURL(${WP_BASE_URL}/wp-admin/);

// Expect a specific element on the dashboard to be visible

await expect(page.locator(‘#wpadminbar’)).toBeVisible(); // Admin bar

await expect(page.locator(‘h1:has-text(“Dashboard”)’)).toBeVisible(); // Dashboard heading

});

test(‘should prevent login with invalid credentials’, async ({ page }) => {

// Fill in username with valid, password with invalid

await page.fill(‘#user_login’, WP_ADMIN_USERNAME);

await page.fill(‘#user_pass’, ‘wrong_password’); // Use an intentionally wrong password

// Click the “Log In” button

await page.click(‘#wp-submit’);

// Expect to still be on the login page (or redirected back to it)

await expect(page).toHaveURL(${WP_BASE_URL}/wp-login.php?); // WordPress often appends query params on failed login

// Expect the error message to be visible

await expect(page.locator(‘#login_error’)).toBeVisible();

await expect(page.locator(‘#login_error’)).toContainText(‘Unknown username or incorrect password.’);

});

test(‘should allow logging out’, async ({ page }) => {

// First, log in (we’re reusing the valid login sequence)

await page.fill(‘#user_login’, WP_ADMIN_USERNAME);

await page.fill(‘#user_pass’, WP_ADMIN_PASSWORD);

await page.click(‘#wp-submit’);

await expect(page).toHaveURL(${WP_BASE_URL}/wp-admin/);

// Hover over the “Howdy, [username]” link in the admin bar

await page.hover(‘#wp-admin-bar-my-account a.ab-item’);

// Click the “Log Out” link that appears in the dropdown

await page.click(‘#wp-admin-bar-logout a’);

// Expect to be redirected to the login page

await expect(page).toHaveURL(${WP_BASE_URL}/wp-login.php?action=logout&_wpnonce=*);

// Expect the “You are now logged out.” message

await expect(page.locator(‘#login’)).toContainText(‘You are now logged out.’);

});

“`

Key Playwright Actions Used

page.goto(${WP_BASE_URL}/wp-admin);: Navigates to the WordPress admin login page.
page.fill('#user_login', WP_ADMIN_USERNAME);: Fills an input field. #user_login is the CSS selector for the username input on the WP login page.
page.click('#wp-submit');: Clicks a button or link. #wp-submit is the CSS selector for the login button.
expect(page).toHaveURL(...): Asserts that the browser’s current URL matches the expected one.
expect(page.locator('#wpadminbar')).toBeVisible();: Locates an element and asserts its visibility.
page.hover('#wp-admin-bar-my-account a.ab-item');: Simulates hovering over an element, which is necessary to make the logout link visible in the admin bar.
expect(page.locator('#login')).toContainText('...');: Asserts that an element contains specific text. Be careful with exact text matches as they can change. Partial text or regex is often more robust.

Testing Content Creation and Management

Now we’re in the admin area, let’s test a common task: creating a new post.

Adding a New Post Test

Create tests/post-creation.spec.js.

“`javascript

// tests/post-creation.spec.js

require(‘dotenv’).config();

const { test, expect } = require(‘@playwright/test’);

const WP_BASE_URL = process.env.WP_BASE_URL;

const WP_ADMIN_USERNAME = process.env.WP_USERNAME;

const WP_ADMIN_PASSWORD = process.env.WP_PASSWORD;

test.describe(‘WordPress Post Creation’, () => {

test.beforeEach(async ({ page }) => {

// Log in before each test in this describe block

await page.goto(${WP_BASE_URL}/wp-admin);

await page.fill(‘#user_login’, WP_ADMIN_USERNAME);

await page.fill(‘#user_pass’, WP_ADMIN_PASSWORD);

await page.click(‘#wp-submit’);

await expect(page).toHaveURL(${WP_BASE_URL}/wp-admin/);

});

test(‘should allow creating and publishing a new post’, async ({ page }) => {

const postTitle = Playwright Test Post - ${Date.now()}; // Unique title

const postContent = ‘This is content from an automated Playwright test.’;

// Navigate to “Add New Post” page

await page.goto(${WP_BASE_URL}/wp-admin/post-new.php);

await expect(page).toHaveURL(${WP_BASE_URL}/wp-admin/post-new.php);

await expect(page.locator(‘h1:has-text(“Add New Post”)’)).toBeVisible();

// Fill in the post title

await page.fill(‘#post-title-0’, postTitle); // Gutenberg editor title input

// Fill in the post content (using Gutenberg’s default paragraph block)

await page.click(‘button[aria-label=”Add block”]’); // Click the ‘+’ button to add a block

await page.fill(‘textarea[aria-label=”Add title”]’, postTitle); // Old editor title

await page.fill(‘p[class*=”wp-block-paragraph”]’, postContent); // Gutenberg paragraph

// Wait for the publish button to become active

await page.waitForSelector(‘button.editor-post-publish-button’, { state: ‘visible’ });

// Click the ‘Publish’ button (Gutenberg)

await page.click(‘button.editor-post-publish-button’);

// A second ‘Publish’ click might be needed for confirmation in Gutenberg

await page.waitForSelector(‘.editor-post-publish-button__button:has-text(“Publish”)’, { state: ‘visible’ });

await page.click(‘.editor-post-publish-button__button:has-text(“Publish”)’);

// Expect success message

await expect(page.locator(‘.components-snackbar-list .components-snackbar’)).toContainText(‘Post published.’);

// Verify the post appears on the frontend

// Get the permalink from the success message or URL

const viewPostLink = await page.locator(‘.components-snackbar__content a’).first();

const postPermalink = await viewPostLink.getAttribute(‘href’);

expect(postPermalink).not.toBeNull();

await page.goto(postPermalink);

await expect(page.locator(‘h1.entry-title’)).toContainText(postTitle); // Assuming standard theme post title selector

await expect(page.locator(‘.entry-content’)).toContainText(postContent); // Assuming standard theme content selector

});

// You could add a test to delete the post here or clean up later

test(‘should allow deleting a published post’, async ({ page }) => {

// This test would require finding an existing post and deleting it.

// For brevity, it’s a placeholder. A real implementation would:

// 1. Create a post (or use an existing one setup by global-setup.js)

// 2. Navigate to Posts List (wp-admin/edit.php)

// 3. Find the post by title

// 4. Hover over it to reveal action links

// 5. Click ‘Trash’

// 6. Confirm deletion

// Alternatively, use the WordPress REST API for setup/teardown.

await test.skip(‘Deleting posts is complex and would be better handled with API or global setup’);

});

“`

Challenges with WordPress Content Editors

Classic Editor vs. Gutenberg: The provided code primarily targets the Gutenberg editor. If your site uses the Classic Editor plugin, the selectors for title and content fields will be different (#title for title, #content for the editor).
Iframes: The Classic Editor is often within an iframe (TinyMCE). Playwright can interact with iframes, but it adds a layer of complexity (await page.frameLocator('iframe#content_ifr').locator('body#tinymce').fill(...)).
Dynamic UI: Gutenberg’s UI is quite dynamic. Locators like button.editor-post-publish-button are relatively stable, but specific nuances might require careful observation using Playwright’s Codegen or Inspector tools.

When considering how to implement end-to-end testing for a WordPress site with Playwright, it’s also beneficial to explore related topics that can enhance your testing strategy. For instance, you might find valuable insights in an article about optimizing WordPress performance, which can directly impact your testing outcomes. You can read more about it in this informative blog post that discusses various techniques to improve site speed and reliability, ensuring that your end-to-end tests yield accurate results.

Advanced Scenarios: Forms, User Roles, and Custom Elements

WordPress sites often have custom forms, specialized user roles, and unique theme/plugin elements. Playwright handles these just fine.

Testing a Contact Form

Let’s assume you have a simple contact form, perhaps powered by Contact Form 7 or WPForms, on a page like /contact.

“`javascript

// tests/contact-form.spec.js

require(‘dotenv’).config();

const { test, expect } = require(‘@playwright/test’);

const WP_BASE_URL = process.env.WP_BASE_URL;

test.describe(‘Contact Form’, () => {

test(‘should allow submitting the contact form’, async ({ page }) => {

await page.goto(${WP_BASE_URL}/contact); // Adjust to your contact page URL

await expect(page).toHaveURL(${WP_BASE_URL}/contact/);

// Fill in form fields (adjust selectors based on your form)

await page.fill(‘input[name=”your-name”]’, ‘Playwright Test User’);

await page.fill(‘input[name=”your-email”]’, ‘test@example.com’);

await page.fill(‘input[name=”your-subject”]’, ‘Automated Test Message’);

await page.fill(‘textarea[name=”your-message”]’, ‘This is an automated message sent via Playwright.’);

// Click the submit button

await page.click(‘input[type=”submit”]’); // Common selector for CF7

// Expect a success message (adjust selector/text for your form plugin)

await expect(page.locator(‘.wpcf7-response-output’)).toBeVisible();

await expect(page.locator(‘.wpcf7-response-output’)).toContainText(‘Thank you for your message. It has been sent.’);

// Optional: Check if the form clears or redirects

// await expect(page.locator(‘input[name=”your-name”]’)).toHaveValue(”);

});

test(‘should display validation errors for empty fields’, async ({ page }) => {

await page.goto(${WP_BASE_URL}/contact);

await page.click(‘input[type=”submit”]’); // Submit without filling anything

// Expect validation errors to appear (adjust selectors for your form plugin)

await expect(page.locator(‘.wpcf7-not-valid-tip’)).toHaveCount(4); // Or specific error messages

await expect(page.locator(‘.wpcf7-form-control-wrap input[type=”text”].wpcf7-not-valid’)).toBeVisible();

});

“`

Testing Different User Roles

Beyond admin, you might have editors, authors, subscribers. You can parameterize your login tests to use different credentials.

Using test.use(): Playwright allows configuring contexts for groups of tests.
Separate credential sets: Store multiple WP_EDITOR_USERNAME, WP_EDITOR_PASSWORD, etc., in your .env.

“`javascript

// tests/editor-post.spec.js (example fragment)

// … same setup as admin-login.spec.js

const WP_EDITOR_USERNAME = process.env.WP_EDITOR_USERNAME;

const WP_EDITOR_PASSWORD = process.env.WP_EDITOR_PASSWORD;

test.describe(‘WordPress Editor Role Functionality’, () => {

test.beforeEach(async ({ page }) => {

// Log in as an editor

await page.goto(${WP_BASE_URL}/wp-admin);

await page.fill(‘#user_login’, WP_EDITOR_USERNAME); // Use editor credentials

await page.fill(‘#user_pass’, WP_EDITOR_PASSWORD);

await page.click(‘#wp-submit’);

// Expect to be on dashboard, but with editor specific capabilities

await expect(page).toHaveURL(${WP_BASE_URL}/wp-admin/);

await expect(page.locator(‘#menu-posts’)).toBeVisible(); // Editors can see posts menu

await expect(page.locator(‘#menu-plugins’)).not.toBeVisible(); // Editors cannot see plugins menu

});

test(‘editor should be able to edit their own post’, async ({ page }) => {

// … test flow for an editor editing a post they authored

});

“`

Interacting with Custom Elements

Any custom HTML, JavaScript, or CSS added by your theme or plugins can be targeted.

Inspect with browser dev tools: Use your browser’s developer tools (F12) to find unique CSS classes, IDs, or data attributes for elements you want to interact with or assert against.
Playwright Codegen: Run npx playwright codegen your-wp-site.com to open a browser and generate Playwright code as you interact with the page. This is fantastic for getting started with selectors.

When considering how to implement end-to-end testing for a WordPress site with Playwright, it’s also beneficial to explore related topics that can enhance your understanding of web testing frameworks. For instance, you might find valuable insights in an article about the importance of automated testing in web development, which can provide a broader context for your testing strategies. You can read more about it in this informative piece that discusses various testing methodologies and their applications.

Maintenance and Best Practices for WordPress E2E Tests

Writing tests is one thing; maintaining them is another. Especially with WordPress and its ecosystem, things can change.

Keep Selectors Robust

Avoid fragile selectors: Don’t use selectors that depend on exact class names that might be generated dynamically or change with a theme update (.button-primary.my-custom-class.some-other-class).
Prioritize IDs: IDs are best as they should be unique (e.g., #user_login, #wp-submit).
Use descriptive attributes: data-testid="...", aria-label="...", role="..." are excellent targets.
Text-based locators: page.locator('text=Log In') or page.locator('button:has-text("Publish")') are often robust for static text elements.
Locator chaining: page.locator('#primary-menu').locator('li').first() helps narrow down elements.

Atomic Tests and Setup/Teardown

Each test should be independent: Don’t rely on the outcome of a previous test.
beforeEach / afterEach: Use these hooks for common setup (like logging in) or cleanup (like deleting created data).
Global Setup/Teardown: For more complex scenarios, Playwright offers globalSetup and globalTeardown scripts (configured in playwright.config.js). You could use these to:
Programmatically create a WordPress user via the REST API before tests run.
Create a specific post or page.
Clean up all test data after all tests have completed. This is often more reliable than trying to clean up within each test.

Configuration (`playwright.config.js`)

Playwright provides a configuration file (playwright.config.js in your project root) where you can define global settings.

Base URL: You can set a baseURL here, simplifying page.goto('/').
Browser projects: Define which browsers to test against.
Timeouts: Adjust default timeouts if your WordPress site is particularly slow.
Retries: Configure retries for flaky tests.

Here’s an example playwright.config.js:

“`javascript

// playwright.config.js

require(‘dotenv’).config();

const { defineConfig, devices } = require(‘@playwright/test’);

module.exports = defineConfig({

testDir: ‘./tests’,

fullyParallel: true, // Run tests in parallel

forbidOnly: !!process.env.CI, // In CI, forbid “test.only”

retries: process.env.CI ? 2 : 0, // Retries on CI for flakiness

workers: process.env.CI ? 1 : undefined, // Limit workers on CI to save resources

reporter: ‘html’, // Generate an HTML report

use: {

baseURL: process.env.WP_BASE_URL || ‘http://localhost:8080’, // Fallback for local dev

trace: ‘on-first-retry’, // Capture trace for failed tests

video: ‘on-first-retry’, // Capture video for failed tests

projects: [

{

use: { …devices[‘Desktop Chrome’] },

{

use: { …devices[‘Desktop Firefox’] },

{

use: { …devices[‘Desktop Safari’] },

});

“`

Continuous Integration (CI)

Integrate your Playwright tests into your CI/CD pipeline (e.g., GitHub Actions, GitLab CI, Jenkins). This ensures that every code change is automatically tested, catching regressions early.

Example GitHub Actions workflow (.github/workflows/playwright.yml):

“`yaml

on:

push:

branches: [ main, develop ]

pull_request:

branches: [ main, develop ]

jobs:

test:

timeout-minutes: 60

runs-on: ubuntu-latest

steps:

uses: actions/checkout@v3
uses: actions/setup-node@v3

with:

node-version: 18

name: Install dependencies

run: npm ci

name: Install Playwright browsers

run: npx playwright install –with-deps

name: Run Playwright tests

env:

WP_BASE_URL: ${{ secrets.WP_STAGING_URL }} # Use a secret for your staging URL

WP_USERNAME: ${{ secrets.WP_STAGING_USERNAME }}

WP_PASSWORD: ${{ secrets.WP_STAGING_PASSWORD }}

run: npx playwright test

uses: actions/upload-artifact@v3

if: always()

with:

path: playwright-report/

retention-days: 30

“`

Remember to set your WP_STAGING_URL, WP_STAGING_USERNAME, and WP_STAGING_PASSWORD as GitHub Secrets for security.

Debugging

Playwright has excellent debugging tools.

--debug: Run npx playwright test --debug to launch Playwright Inspector, allowing you to step through tests, inspect elements, and generate selectors.
page.pause(): Insert await page.pause(); into your test code to pause execution at any point and inspect the browser state.
Screenshots/Videos: Configure playwright.config.js to capture screenshots and videos on test failures, which are invaluable for asynchronous issues.

You now have a solid foundation for implementing end-to-end testing for your WordPress site using Playwright. Starting small, focusing on critical user flows, and incrementally adding more tests will provide significant value in ensuring your WordPress projects remain robust and reliable. Happy testing!

How to implement end-to-end testing for a WordPress site with Playwright?

Why Playwright for WordPress?

Node.js and npm Installation

Initializing Your Project

Installing Playwright

Crafting Your First WordPress Test

Creating Your Test File

Writing the Homepage Test

Understanding the Code

Running Your First Test

Testing WordPress Login and Admin Functionality

Storing Credentials Securely

.env

Writing the Login Test

Key Playwright Actions Used

Testing Content Creation and Management

Adding a New Post Test

Challenges with WordPress Content Editors

Advanced Scenarios: Forms, User Roles, and Custom Elements

Testing a Contact Form

Testing Different User Roles

Interacting with Custom Elements

Maintenance and Best Practices for WordPress E2E Tests

Keep Selectors Robust

Atomic Tests and Setup/Teardown

Configuration (playwright.config.js)

Continuous Integration (CI)

Debugging

Configuration (`playwright.config.js`)