(Accompanies associated blog post on Katie Kodes "Running UI tests in GitHub Actions".)
- 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.
- 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, puttingschedule
at the same level asworkflow_dispatch
above it and indenting the 1-member list starting with- cron
inside of `schedule):schedule: - cron: "43 2 * * *"
- 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.)
I've done a few strange things I'd like to draw your attention to.
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 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:
- a hardcoded real-world URL,
- a dynamically computed real-world URL (e.g. the preview URL returned by the Azure Static Web Apps GitHub Action),
localhost
,- etc.
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.