Front End Testing with GitHub Actions • Amy Kapernick • YOW! 2025
This presentation by Amy Kapernick at YOW! Australia 2025 details how to implement robust front-end testing using GitHub Actions. It covers the rationale for comprehensive front-end testing, the necessity of a live deployment preview, and practical steps for automating tests like Lighthouse for performance/accessibility and Playwright for UI validation. The talk also delves into continuous deployment workflows and explores GitHub Actions' broader utility for workflow automation beyond testing, such as generating issues from code comments.
Amy Kapernick presents on the critical role of front-end testing, particularly leveraging GitHub Actions for automation. She emphasizes that despite widespread agreement on the importance of testing, front-end tests often get overlooked. However, the front-end is the user’s first impression, and issues here can significantly degrade user experience, even if the backend is robust.\n\n## The Imperative for Front-End Testing\nKapernick highlights the diverse range of front-end tests required, including accessibility, performance, user testing, HTML validation, and visual regression testing. A core challenge is that most front-end tests necessitate a functioning front-end to run against, unlike unit tests that can use dummy data. Linting and validation provide some insight, but they cannot fully predict the final user experience or visual impact of code changes. This need for a live environment is crucial, especially for performance testing, which requires a setup as close to production as possible to yield meaningful results.\n\n## Why Automate with GitHub Actions?\nThe presentation strongly advocates for automating tests, particularly repetitive tasks, to ensure consistency and confidence. Automation guarantees that tests run predictably and thoroughly, preventing untested code from being merged and thereby protecting application quality. While acknowledging alternatives like Azure DevOps, CircleCI, or Bitbucket Pipelines, Kapernick explains her choice of GitHub Actions due to its robust documentation, community support, and extensibility for both personal and enterprise projects.\n\n### GitHub Actions Fundamentals\nGitHub Actions operates through workflows, defined in YAML files within the .github/workflows directory. Workflows comprise one or more jobs, which run concurrently by default, and each job consists of sequential steps. A failed step halts the entire job. Key workflow elements include:\n* name: A user-friendly name for the workflow.\n* on: Triggers for the workflow, such as pull_request events (opened, reopened, synchronized), which can be filtered by branch or file changes.\n* jobs: Individual tasks, each with a computer-friendly name.\n* runs-on: Specifies the runner environment (e.g., ubuntu-latest). Windows runners are noted to be more expensive.\n* steps: Individual commands or actions. Steps can utilize existing packages (uses) or run terminal commands (run). They can also have ids for referencing, if conditions for conditional execution, and receive env variables.\n* outputs: Mechanism to pass data (e.g., a deployment URL) between steps and jobs.\n\n## Building and Deploying a Live Preview\nThe initial workflow involves checking out code, setting up Node.js, and installing dependencies (npm install). For creating a live preview, Kapernick demonstrates deploying to Netlify (or other cloud providers like Azure, AWS, Google Cloud). A critical aspect is capturing the generated live URL from the deployment step and outputting it for subsequent jobs.\n\n### The “Secret Values” Gotcha and Workaround\nGitHub Actions has a security feature that redacts secret values (e.g., API keys, project IDs) from logs and outputs. This becomes problematic when a deployment URL inadvertently contains such a