テスト自動化カンファレンス2025予告：設計原則「関心の分離」からPage Object Modelを学ぼう

テスト自動化カンファレンス2025に採択されました。ありがとうございます！！

前回やったと同じように、Confengineの「プロポーザル」形式で発表内容を事前に公開します。

これは現状作っているスライドの内容から作ったもので、実際に提出したプロポーザルの記述と異なる点をお気をつけください。

ただ、当日発表する内容はプロポーザル記述に沿った内容を踏まえたもので、だいたい同じです（だと思っています）。

「こういうプロポーザルを出したから採択される」でもないですし、「こういうプロポーザルを出さないと採択されない」でもないです。

この記事を出す意図は、事前に私の発表を、スクラムフェスと同じくらいに完全ネタバレしておくことで、聴講者の方の理解を深めたり、期待を揃えることです。

「AIが書いたから安心」といってE2Eテストコードを書いている人、ヤバいです。

WebのE2E自動テストにおける代表的なパターンであるPage Object Model (POM) は、ソフトウェア設計における重要な概念である「関心の分離」や「単一責務の原則」を実現したものとなっています。

しかし、昨今の生成AIの普及により、POMの構造を単に模倣した「ポチョムキン理解」によるコードが大量に生成されるようになったと考えています。

これらのコードはPageとテストで分離されているように見えます。

しかしながら、本質的な設計原則を欠いているため、修正コストがかかったり、テストの内容が不明瞭なテストが大量に生成されるという深刻な問題を引き起こしています。

テスト自動化エンジニアのみなさんとこの問題を共有し、一緒に対処する方法を考えたいと思っています。

本セッションでは、具体的なコードのアンチパターン（Page Object内でのアサーション、巨大クラス化など）に指摘を入れながら、POMとソフトウェア設計の基本原則である「関心の分離」「単一責務の原則」の関係を掘り下げます。

「設計思想を理解すること」の重要性と、それによって発揮できる「批判的なレビュー能力」を養うことを目指します。

導入：生成AI時代のテスト自動化現場で起こっていること
- 敏腕リーダーの指示と生成AIコードの単純受容によって生じる現場の課題提起。
- 「修正が終わらない」「何をテストしているかわからない」の原因。
根源への回帰：普遍的な「設計原則」の説明
- ソフトウェア設計原則（SWEBOK参照）の定義。
- 核となる原則：「関心の分離」と「単一責務の原則」のテスト自動化における解釈。
POMの解説とアンチパターン考察
- POMの本来の目的：「テストの関心事（What）」と「ページの関心事（How）」の分離。
- 生成AIが陥りやすい「ポチョムキンPOM」の解説。
- 具体的なアンチパターン事例（Page Object内のアサーション、巨大クラス、密結合など）とその問題点。
テスト自動化エンジニアとして我々はどうしていくか
まとめ

本セッションに参加することで、参加者は以下の知識と能力を獲得できます。