Rebuilding my trust in testing with GitHub Actions

Testing is a critical piece of application development, whether it be testing yourself in the browser, or making automated assertions based on test suites you've previously written.

Don't get slack

I'll be the first to admit that I have been guilty of being a bit slack on testing. However, with the migration to GitHub, and the ease that GitHub Actions allows us to implement some consistency checking, it's given me a new perspective on running feature and unit tests.

Its easy to forget the importance of tests that have already been written. To make sure I don't cross the line and ignore what my tests are telling me, I've implemented a GitHub action to run tests before a merge on almost all of the Laravel projects we manage. It's simple, it's quick and its effective. At just 34 lines, this YAML snippet ensures all my tests are passing whenever we make a PR to a release branch.

I know we're not reinventing the wheel here, but this site is as much about being a memory store for me and a quick reference when I need it, as it is to share with others.

.github/actions/tests.yaml

name: Tests

on:
  pull_request:
    branches:
      - release/*

permissions:
  contents: read

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - name: Setup PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: '8.2'
          extensions: pdo, sqlite, pdo_sqlite, gd

      - uses: actions/checkout@v4

      - name: Cache Composer packages
        uses: actions/cache@v4
        with:
          path: vendor
          key: project-${{ hashFiles('**/composer.lock') }}

      - name: Install composer dependencies
        run: composer install -o --no-interaction --no-scripts --ignore-platform-req=ext-*

      - name: Run tests
        run: ./vendor/bin/pest --parallel

Remembering the importance

Why wouldn't I want to ensure the integrity of my code before pushing it across to a major branch? It can feel inconvenient to write tests for everything, but it's a mindset shift, TDD is - at least when you get used to it - a much faster way of shipping code. I love that feeling of having all my tests passing and knowing that when I plug this feature in to a web page or API, the chances of it working first time are very high.

Even if it does take a little longer, you've then got those tests to back up the future you, or a developer who begins working on your code. It also helps to build documentation on exactly what the code should be doing.

Oh, and as you may have noticed above I'm using Pest. It's got such a great feel to it, it just makes testing that little bit less of a headache.