朝6時にアラームが鳴るより前に目が覚めた。
半年前の自分なら、日曜日の朝6時に目覚ましより先に起きることなんてなかった。でも今は違う。昨夜セットしたGitHub Actionsのワークフローが気になって、ベッドの中でスマホを開いた。
画面に表示されたのは、緑色のチェックマークの列だった。
Playwrightを導入したのは3週間前のことだ。
ブログプラットフォームの機能が増えてきて、手動で全ページを確認するのが現実的じゃなくなっていた。記事の表示、SNSカードのOGP、管理画面のダッシュボード、音声プレイヤーの再生。一つ直すと別の何かが壊れる。人事の世界では「モグラ叩き」と呼ばれる状態。エンジニアリングでは「リグレッション」と呼ぶらしい。
手動テストの限界が来た。ページが増えるたびに確認漏れが出る。自動化したい。
Playwrightがおすすめです。ブラウザを自動操作してE2Eテストを実行できます。Astroプロジェクトとの相性もいいですし、GitHub Actionsでの自動実行も簡単にセットアップできます。
テストコードを書くってこと？ テストを書くためのコードを書く、って、なんか入れ子みたいだな。
いい直感です。テストコードは「このプロダクトはこう動くべきだ」という仕様書でもあります。書くことで、自分のプロダクトへの理解が深まりますよ。
テストを書く作業は、想像以上に面白かった。
「トップページにアクセスしたら、ブログ記事の一覧が表示される」。「記事をクリックしたら、本文が表示される」。「管理画面はログインしないとアクセスできない」。当たり前のことを、一つずつコードにしていく。
人事でいえば、評価制度の要件定義に似ている。「マネージャーは四半期ごとに評価を入力する」「評価は5段階で、各段階に定義がある」。当たり前のことを、一つずつ文書にする。その作業の退屈さと重要さを、僕は9年間知っていた。
アラタ: ブログ記事の一覧表示、個別記事の表示、OGPメタタグの確認、管理画面の認証チェック、SNSダッシュボードのデータ表示。この5つのテストシナリオを実装したい。 クロ: いいテスト設計ですね。まずはページオブジェクトパターンで共通操作を抽出して、各シナリオをdescribeブロックで整理しましょう。
テストコードは3日かけて書いた。途中で何度もエラーが出た。セレクタが見つからない、タイムアウトする、非同期処理の待ち方がわからない。でも、一つずつ直していった。
そして昨夜、全てのテストをCI上で走らせるワークフローを書いた。
アラタ: GitHub ActionsでPlaywrightを動かすワークフローを設定した。pushのたびに全テストが自動実行される。 クロ: playwright.ymlの設定、確認しました。問題なさそうです。手動で一度トリガーして確認しましょうか？ アラタ: もう深夜だから、明日の朝確認する。
そして今朝。スマホの画面で見た緑のチェックマーク。
✓ blog-list.spec.ts (3 tests passed)
✓ blog-post.spec.ts (5 tests passed)
✓ ogp-meta.spec.ts (4 tests passed)
✓ admin-auth.spec.ts (3 tests passed)
✓ sns-dashboard.spec.ts (2 tests passed)
17 passed, 0 failed17件のテスト。全てグリーン。
ベッドの上で、しばらくその画面を見つめていた。
テストが通ったこと自体は、技術的にはそれほど大したことじゃないのかもしれない。ハッチに言わせれば「当たり前のことをやっただけ」だろう。
でも、僕にとっては違った。
半年前、「how do i log errors」と打ち込んだ人間が、今、17件のE2Eテストを書いて、CIで自動実行させて、全件パスしている。自分が作ったプロダクトが正しく動いていることを、機械が証明してくれている。
お、テスト書いたのか。CI回してるし。やるじゃん。
朝起きたら全部グリーンだった。なんか、嬉しくて。
テスト通った朝はいいもんだろ。エンジニアはみんなあの快感のために仕事してるようなもんだ。
朝のコーヒーを淹れながら、考えた。人事の仕事には、こういう瞬間がない。採用が成功したのかどうかは、何年も経たないとわからない。評価制度が正しいのかどうかは、永遠にわからないかもしれない。
でもテストは、今朝、17件全て、グリーンだった。
それは小さいけれど、確かな証明だった。