テストへのスタンス
個人開発（趣味）レベルですが、テストに対するスタンスについて簡単に書きます。
コードレビュー
物量に圧倒されるプロダクションコードとテストコードをレビューするのは、
書く工程が減ったため読む深みが浅くなっています。
DIPやインターフェースを整えたり、純粋関数に寄せたりなど創意工夫を施してテスタビリティを上げても、
単体テストコードや結合テストコードをノールックに近い見方でレビューする傾向が増えつつあります。
以下の記事のように、プロダクションコードをそのまま写経しただけの単体テストコードは削除しました。
Zod 等のスキーマバリデーションや、
Storybook アクセシビリティチェックやVRT、
SonarQubeによるコードチェック、
ミューテーション、モンキー、
独自AST・Codemod、独自リンターなどで守るべきものは残しています。
（ここのバリエーションは本当に増えています...）
最近ではレビュー依頼が来たら3者のAIエージェントにレビューをさせて報告させることが多く、
UI・UXのレビューチェックは私、と分担することにしています。
仕様については、Design Doc や ADR などをコードベースにコミットして把握させます。
CIでE2E
私のブログで散々書いている Testcontainers + Playwright + Cucumber.js のE2Eテストを、
CI として動かすようにしています。
GitHub Action や CircleCI で動かすようにしています。（お金の都合です）
単体・結合テストに比べて、E2Eテストは実行時間は確かに遅いですが、
設計次第で10分前後で終わることが多いです。
メンテナンスコストにおいては、FE・BEを分けた構成なのであれば、
FE側にPage Object Modelを置いたり、BE側にシードやスクリプトファイルを置くなどして、
近しい箇所にあればアプリ側の修正と一緒にするなどでコストを下げれます。
Testcontainers でDB自体も建てるため、基本的に外部依存が少ないため、
フレーキーになることは少ないです。
またエラー発生時のトラブルシューティングも Testcontainers 内部に閉じるので、
トレースしやすいし、AI にやらせて治させます。
欠点は、真の意味でE2Eテストではないところです。
GitHub OAuthなどの外部依存する箇所は外部通信をインターセプトしてレスポンスを返すようにしているため、
外部サービスのレスポンスが変わったり挙動が変わったりといったところには気づけません。
よくある本番に近い環境で、それらのパターンだけは手動テストする必要は残っています。
外部依存があると不安定になるため、意図的な設計にしています。
ただし禁止事項は、E2Eテストコード分岐をプロダクションコードに入れないことです。
先のような外部通信のインターセプトや環境変数による変更のみを許容しています。
動画でチェック
コードレビューは、先ほどのE2Eテストの動作をPlaywrightの動画撮影させてストレージにアップさせます。
動画なら期待する振る舞いを視覚的に判断できる ので、それで把握するようにしています。
もはや自作コストは低くなっているため、影響した箇所の動画だけ見るようにしたり、
データベースのデータ変化をグラフィカルに表示するようにするなどで、
人間が見やすい視覚的な結果をレビューすることにしてます。
これは扱うプロダクトによっては見るべきものは変わってきますが、
私の場合は ブラウザ操作の動画を見るだけで十分です。
振る舞いについては、自然言語でCucumber.jsによるマークダウンファイルを読めば分かるし、
動画ファイルも添付されているので、それも見ればさらに理解が深まります。
ロジックが複雑な流れになるようなら、mermaidやdrawioなどの図で読めるようにして、
レビューしやすいような視覚的な表現にしています。
終わりに
以上、現時点でのテストへのスタンスでした。
-
s※ ログイン不要で投稿できます。
※ 同じブラウザから投稿を削除できます。
0
読み込み中...
関連する記事
タグ「テスト」の記事
Testcontainers + Playwright + Cucumber.js による受け入れテストを、公私ともに活用しています。 運用していて気づいた点について、また書き残そうと思います。 開発PR単位でE2Eテスト これはTestc
2026年09月07日
テストコードをテストする、ミューテーションテスト。 プロダクションコードを突然変異でコードを書き換えたら（ミューテーション）、テストが失敗してくれるかどうか。 失敗するということは、不具合を検知できたということです。 ミューテーションする箇
2026年08月25日
お仕事先のWebアプリケーションに、Testcontainersを導入運用して数ヶ月経過しました。 良い点と困る点について、書き残しておきます。 前提 簡単な前提として、バックエンドDB・APIとフロントエンドの3層構成のよくあるWebアプ
2026年07月08日