Skip to content

4-file (plus README) automated user interface (“UI”) testing codebase, using Playwright in Node.js, that lets GitHub Actions validate nightly at 2:43AM (UTC) that the <title> tag of katiekodes.com still has the phrase “Katie Kodes” in it.

kkgthb/qa-auto-ui-001-playwright-js-min-viable-build

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

10 Commits
 
 
 
 
 
 

Repository files navigation

A tiny Playwright (via Node.js JavaScript) user interface (UI) test

(Accompanies associated blog post on Katie Kodes "Running UI tests in GitHub Actions".)


Instructions

  1. Under the "Use this template dropdown at the top-right of the original repository hosting this tutorial, click "Create a new repository" and go through the steps to make your own repository based off of this one.
  2. Edit the /.github/workflows/run-playwright.yaml file and uncomment out the following 2 lines of code if you actually want it to run nightly at 2:43 AM
    (remove the extra "# "from each line, being sure to leave YAML-appropriate indentation where it does still belong, putting schedule at the same level as workflow_dispatch above it and indenting the 1-member list starting with - cron inside of `schedule):
      schedule:
        - cron: "43 2 * * *"
  3. Wait for 2:43 AM UTC to come around and watch in amazement as GitHub Actions validates that the "Katie Kodes" blog indeed still says "Katie Kodes" in its HTML title tag.
    (Note: It may run many minutes after 2:43AM UTC, because GitHub Actions schedules aren't exactly guaranteed.)

Warnings

I've done a few strange things I'd like to draw your attention to.

There is no website build

The entire Node.js-based codebase, with its package.json, etc., has no code in it whatsoever pertaining to the process of making katiekodes.com exist on the open internet.

This is not normal.

Usually, I would have chosen Node.js/JavaScript as a language in which to write my Playwright unit test(s) if the website I'm testing were one that already gets built in, or runs on, Node.js/JavaScript.

There wouldn't be an entire package.json file dedicated to unit testing alone.

Instead, I'd expand the contents of my website's codebase's package.json to use Playwright as a dependency, and I'd add a playwright.config.js to the same root folder of my website's codebase that includes its package.json.

The URL to test against is parameterized

The URL katiekodes.com whose <title> tag I'm checking the contents of gets set in /.github/workflows/run-playwright.yaml, not in /e2e-test-codebase/my-e2e-tests/my-first-tests.spec.js.

That seems potentially nifty for making it easy to if-then-else whether to test against:

  1. a hardcoded real-world URL,
  2. a dynamically computed real-world URL (e.g. the preview URL returned by the Azure Static Web Apps GitHub Action),
  3. localhost,
  4. etc.

Node packages install slowly

In a real-world project, /.github/workflows/run-playwright.yaml would run npm ci to install dependencies like Playwright out of a package-lock.json file, not run npm i to install them out of a package.json file, because that can make the GitHub Action run faster.

I used a slower-running approach so that I could keep this file easier to read for beginners.

About

4-file (plus README) automated user interface (“UI”) testing codebase, using Playwright in Node.js, that lets GitHub Actions validate nightly at 2:43AM (UTC) that the <title> tag of katiekodes.com still has the phrase “Katie Kodes” in it.

Topics

Resources

Stars

Watchers

Forks