Building Confidence: CI, Local Tests

Introduction

This week, I set up automated test runs using GitHub Actions, cleaned up and strengthened our Vitest cases for the utility functions, and wrote documentation to help bring these practices into other repos. Now we’ve got a workflow that flags issues right away and encourages contributors to keep our quality standards high.

Why Continuous Integration Was the Missing Piece

Until this week, the project relied on developers remembering to run npm test before pushing. That’s fine when you’re solo and hyper-disciplined, but it doesn’t scale. CI rebuilds on neutral infrastructure, executes the Vitest suite, and blocks merges when tests fail.

Executive Summary

• Added a GitHub Actions workflow (.github/workflows/ci.yml) that runs npm ci and npm run test:run on every push or pull request targeting main.
• Hardened src/utils.test.ts with boundary cases, empty-input handling, and multi-line formatting checks so regressions surface immediately.
• Outlined an upstream contribution plan (UtilsIncludeTest in tests/utils_test.cpp) to ensure onlyIncludedExtensions handles real-world include lists, whitespace, negative matches, and empty configurations.

The repository now fails fast when tests break, documents how to keep contributions safe, and provides a blueprint for sharing those habits beyond this codebase.

Workflow Highlights

name: CI
on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm
      - run: npm ci
      - run: npm run test: run

Key lessons:

1. YAML indentation matters: My first draft began with - name: CI, so GitHub treated the workflow as an array element and ignored it. Removing the dash turned the lights on.
2. Lock files are non-negotiable: actions/setup-node with cache: npm refuses to run if it can’t find package-lock.json. Before this, I didn't include package-lock in the project; I made it ignore it, committing the lock file, which unblocks deterministic installs.
3. Red → Green confidence: I intentionally broke a test, let CI fail, studied the logs, and then fixed it. Watching the status flip from red to green proved that the workflow really guards the repo.