写経テストコードを全部消した

以下で書いた通り、プロダクトコードを写経したテストコードを削除しました。
"こぶりー" ( https://kobliy.vercel.app/ ) という個人ブログを読むアプリのコードです。

テストコードの意味がない

個人開発のバイブコーディングでテストコードを書かせているが意味がなかった。期待する機能をプロンプトで指示しプロダクションコードが出来上がるが、同時にテストコードも書かせていた。そのテストコードは、プロダクションコードをそのままテストコー

ジブンノート

その代わり、以下の構成のテストコードを用意しました。

cucumberとgherkin（日本語マークダウン）でテストシナリオを記述
TestcontainersとPlaywrightでテスト環境を構築

Testcontainers については、以下で書いた記事が参考になります。

Testcontainersで実現する、使い捨て結合テスト環境構築とテスト実施

みなさん、Testcontainersをご存知ですか？Testcontainersは、Dockerコンテナを利用して実際のサービスを統合テストで手軽に使用できるオープンソースのライブラリです。今回、Testcontainersを使って、GitHub Actions上でRails API、MySQL、Next.jsをDockerコンテナとして起動させ、複数のテストシナリオを独立してテストすることができました。以下はその概要図です。本記事では、このテストについての解説と学びを紹介したいと思います。

ジブンノート

システム日付

"こぶりー" では現在日付に関係するロジックがあります。

Web: 未来の日付にあるブログ記事をスキップ
バッチ: 個人ブログ記事を取り込む際に未来の公開日をスキップ

こういう時に Playwrightでのブラウザ日付を固定（2026年6月1日）にしたり、
TestcontainersのDockerコンテナのシステム日付を固定（2026年6月1日）にすることで、
日付に左右されないテストが実現できます。

架空の環境

"こぶりー" では、いくつかの環境を組み合わせています。

Cloud Run: 日々の個人ブログ記事を収集するバッチ
Supabase Edge Functions: データ更新や新着記事の通知などの処理

これらを Testcontainers の中にそのまま格納して環境変数だけ切り替えるだけで、
ローカルのテスト環境だけで全ての機能をチェックすることができます。
ローカル完結するので、テスト速度も早く安定したテストになります。

テスト内容

プロダクションコードを仕様とした写経テストコードは捨てて、
Gherkinのテストシナリオを仕様とさせます。
その代わり、テストシナリオにはこれまで実装してきた機能で守りたい機能のシナリオを記述する必要があります。
「何を守りたいか」を考える必要があり、今のところ思いつくままに列挙しています。
何度書いても冪等なテスト環境なので、何度も実行して検証して形にしました。
ここに書く粒度などは、まだ手探りな状態です。

リファクタリング

守りたい仕様は定義できたので、
codemod によるファイル内の記述をチェック・強制(fix)するのを追加しました。
AIへのプロンプトやコンテキスト、AGENTS.md などによるガードレールよりも、
npm script のfixで直させた方が AI もそちらに沿うように倣ってくれるため、やっておきたいのです。
で、ほぼ大半のts,tsxファイルを変更しましたが、Testcontainersのテストのおかげで安心してマージできました。

フロントエンド

テスト