GitHub Actionsで自動テストを始める：失敗を確認して直す最小のNode.js演習
AIがコードを変更するたびに、人が同じテストを手で実行するだけでは確認を忘れがちです。GitHub Actionsで、変更が提出されたときにテストを実行する手順を作れます。今回は外部パッケージを使わないNode.jsの小さな関数で、成功・失敗・修正の一巡を練習します。
先に「何を確かめるか」を一つ決める
架空のメモアプリで「前後の空白を除いても空なら登録できない」とします。画面全体を一度にテストせず、入力判定の関数から始めます。教材として次の2ファイルを置きます。
// memo.mjs
export function canSaveMemo(text) {
return typeof text === 'string' && text.trim().length > 0;
}// memo.test.mjs
import test from 'node:test';
import assert from 'node:assert/strict';
import { canSaveMemo } from './memo.mjs';
test('空白だけのメモを拒否する', () => {
assert.equal(canSaveMemo(' '), false);
});
test('本文のあるメモを受け付ける', () => {
assert.equal(canSaveMemo(' 確認する '), true);
});ローカルでnode --testを実行し、まず2件とも通ることを確認します。実アプリでは既存テストのコマンドを使ってください。この例では依存のインストールは不要です。
変更の提出時に実行するワークフローを置く
教材リポジトリの.github/workflows/test.ymlへ置く例です。公式資料で案内されているcheckoutとsetup-nodeを使います。実プロジェクトへ追加する前には、利用するNode.jsの版やリポジトリの方針に合わせます。［出典1・2］
name: Tutorial tests
on:
pull_request:
permissions:
contents: read
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v6
- uses: actions/setup-node@v7
with:
node-version: '24'
- run: node --testこの教材では読み取り権限でソースを取得し、テストだけを実行します。APIキーや本番環境の値は渡しません。既存プロジェクトに依存がある場合はロックファイルに基づく準備が必要になりますが、今回の演習に無理に追加する必要はありません。
わざと失敗する変更を作り、ログを読む
学習用ブランチで、関数のtext.trim().lengthをtext.lengthに変更したとします。空白だけの文字列のlengthは0より大きくなるため、1件目が失敗します。この変更を使う目的は、ワークフローが成功表示になることではなく、壊れた仕様を検出できるか確認することです。
| ログの段階 | 見るもの | 扱い |
|---|---|---|
| ソース取得 | 取得の失敗や権限のエラー | 関数の不具合と混ぜない |
| Node.jsの準備 | 指定した版が用意されたか | 環境の問題を切り分ける |
| テスト | 失敗した名前、期待値、実際の値 | 仕様と関数の違いを確認する |
AIに直させるときは期待値を固定する
「空白だけのメモを拒否する」が失敗しています。仕様は前後の空白を除いて空なら拒否です。期待値の変更、テスト削除、失敗の無視をせず、関数の最小修正と理由を提案してください。
修正後は、同じテストが通ったことと、テスト自体を弱めていないことを差分で確認します。既存アプリへ組み込む場合には、他のテストが壊れていないことも必要です。
「CI成功」の意味を限定する
この2件が成功しても、画面の操作、データ保存、セキュリティ、アクセシビリティが確認済みになるわけではありません。どの条件をテストしたかを、結果と一緒に書きます。またこの原稿のワークフローは例であり、実際のGitHub上で実行したログや成功実績は示していません。