Write Playwright Tests for a Gatsby Site

In a site built from gatsbyjs/gatsby-starter-blog the agent reads package.json first: gatsby ^5.14.6 with React 18, ten official plugins and transformers including gatsby-plugin-feed, gatsby-plugin-image, gatsby-plugin-sharp, gatsby-remark-images, gatsby-remark-prismjs, gatsby-source-filesystem and gatsby-transformer-remark, a package-lock.json so npm is the package manager, and scripts for build, develop, serve, clean and format. The test script is the starter's placeholder: it prints a reminder to write tests and exits 1. There is no workflow under .github/, no test runner, and .prettierrc sets arrowParens: avoid and semi: false, so new files must follow that style.

Then it maps what the build will emit. gatsby-config.js points gatsby-source-filesystem at content/blog, configures gatsby-remark-images at 630 pixels wide, and defines the feed with output: /rss.xml built from allMarkdownRemark sorted by date descending. gatsby-node.js creates one page per Markdown post from the same query sorted ascending, passing previousPostId and nextPostId into src/templates/blog-post.js, and sets each post's slug from createFilePath, so the three posts under content/blog become /hello-world/, /my-second-post/ and /new-beginnings/. The template renders the title in an h1 with itemProp="headline", the date formatted MMMM DD, YYYY, the HTML body, the Bio component and a nav.blog-post-nav whose rel="prev" and rel="next" links appear only when a neighbour exists. src/pages/index.js lists posts newest first as article.post-list-item with an h2 link and a small date, and src/pages/404.js and src/pages/using-typescript.tsx are the other routes. hello-world/index.md embeds salty_egg.jpg, which gatsby-remark-images turns into a responsive image wrapper, and new-beginnings/index.md sets a description that Seo puts in the meta tag.

The agent adds @playwright/test as a dev dependency with npm, writes playwright.config.js with a webServer that runs npm run serve against the finished public/ directory on the port gatsby serve reports, and replaces the placeholder test script with playwright test. The specs live in a tests directory, one per area. The home page lists three posts with New Beginnings first and Hello World last, each heading linking to its slug. A post page has the right h1, a date in the configured format, and for Hello World a rendered image inside the article body. Navigation follows gatsby-node.js: the oldest post has only a next link, the newest only a previous link, and the middle one both, with rel attributes the test asserts on. The <title> from Seo reads the post title followed by the site title, and the description meta tag uses the frontmatter description when there is one and the excerpt when there is not. GET /rss.xml answers XML with one item per post, and an unknown path renders the 404 page.

The run executes npm ci, npm run build, npx playwright install chromium, then the suite headless until it passes, then npx prettier --check on the new files so they match .prettierrc. Because every page is static, the tests read the built HTML rather than waiting on hydration, except where a Link click must change the page, and the agent writes those with Playwright's navigation waits. It changes nothing under src/ or content/; if a test reveals a real defect in a page, that goes in the pull request description for a separate change.

The pull request adds playwright.config.js, a tests directory with one spec per area, @playwright/test under devDependencies, the replaced test script and the updated package-lock.json. It changes no page, template, component or post. Its description lists each test with the route it hits and what it asserts, and quotes the Playwright summary from the run.

A reviewer opens the navigation spec first, since it encodes the ordering gatsby-node.js produces and would be the first to break when a post is added: it should derive which post is oldest and newest from the content rather than hard-coding slugs, or name the posts it assumes. Then they check that the feed test counts items against the posts in content/blog, and that the config runs npm run serve against public/ rather than gatsby develop, so the suite tests what a deploy ships.

The session keeps the build log, the Playwright output and every file the agent read before choosing its fixtures. A request to cover the using-typescript page or a new tag page is a follow-up message to the same session, and the agent extends the same branch.

Once the suite exists, run it on every pull request from a GitHub Actions job: npm ci, npm run build, npx playwright install --with-deps chromium and npm test. This repository has no workflow yet, and the agent's pull request adds one when the prompt asks for it.

To have an agent write the same suite for each site started from this template, a handler on your server sends this request with the new repository in resources whenever one is created, using the repository name as the Idempotency-Key, and reads the pull request link from the run.completed webhook on the API key.

A Gatsby build with image processing is the slow part of writing end-to-end tests: build, serve, run, read the failure, fix a selector, build again. In its own sandbox the agent runs that loop on its own machine with its own Chromium, while your checkout and your gatsby develop server stay untouched.

The pull request comes with proof: the build log, the Playwright summary and the transcript showing which posts the agent read before asserting on their titles, dates and neighbours. Several sites built from the same starter can get the request at once, each in its own sandbox.

Why run against gatsby serve instead of gatsby develop?

Will it change my pages or posts?

What happens to the tests when I add a post?

Does it work with yarn or pnpm?