This is an example of a Playwright project that uses the page object model design pattern. In general, Playwright best practices are followed where possible and the configuration is largely the default configuration generated when you install Playwright.

The site under test is Automation Exercise and tests were derived from the Automation Exercise test cases.

pageObjects
    ├── base.page.ts
    ├── base.pageComponent.ts
    ├── pageFixture.ts
    ├── components
        └── *.pageComponent.ts
    └── pages
        └── *.page.ts

This directory contains our base page class, base page component class, and all page object classes that extend those base classes.

• base.page.ts
  • The base page class is intended to include Locators and functionality that is shared across all pages. It takes a Page instance as a constructor parameter.
• base.pageComponent.ts
  • I like to use page components to logically separate page elements that are common across multiple pages from pages themselves. This class takes a Locator parameter in addition to a Page instance. Typically, page components are instantiated within other page classes, and not within the spec file itself.
  • Here's an example where a page component is being instantiated within a page object. Specifically, this the navigation bar component being instantiated within the home page class, as the home page contains the navigation bar. The navigation bar component can then be used in our tests. See here and here.
• pageFixture.ts
  • This is a fixture used to instantiate all of our page objects so they can be used across all of our tests, saving us the hassle of importing and instantiating them in every spec file. You can see how the page objects are passed into our test as parameters, which can then be used throughout the test.

I'm using the @axe-core/playwright for accessibility testing in axe.spec.ts. These are failing miserably on the test site I'm using.

I've made some changes to the Github Actions workflow that Playwright provides.

• I've added caching for the browser binaries. This will speed up the workflow by not having to download the browser binaries every time the workflow runs. See line 37 of the Actions workflow for the first of the steps involved in caching the binaries.
• I've added a step to upload the test report to Github Pages. Note that this report is overwritten on every test run. See the badge at the top of this README for a link to the latest test report and line 71 of the Actions workflow for the steps to upload and deploy the report to Github Pages.
• I'm also using test-reporter for displaying a test report within Actions itself. Here's what this report looks like.