E2E自動テストの ロケーターの使い分けを考えてみたの 2024.02.20 Tue.JaSST nano vol.33 たぬ（@nagatanuen）

たぬ（X: @nagatanuen） SmartHR QAエンジニア 経歴： 某SES（5年） 　株式会社SHIFT（3年） 　株式会社SmartHR（3年） 自己紹介

E2E自動テストのロケーターの使い分けを考えてみたの ● テストコードを書いているときに悩むポイント ● 悩みを解決する方法として考えたこと 今日お話しすること

そもそも話

● システムをエンドユーザーの視点を持って行うテスト ● ユーザーインターフェースやデータベースなど、外部アプリケーションを含 めたシステムの構成要素を全て経由する検証を行う ● あらゆる種類のテストの中でもっとも多くのプロダクションコードが実行され るため退行に対する保護に優れている ● テスト実行に時間がかかる 参考書籍： 単体テストの考え方/使い方 E2Eテストとは

E2E自動テストを実施するためのツールは様々 ● Selenium, Cypress, TestCafe, Playwright　など ● ノーコード・ローコードで利用できるものもある ○ Autify, mabl　など E2E自動テストの種類

Playwrightでテストを書くために必要な準備は、インストールだけです。 テストコードは実装する必要があります。（実装を支援するレコーディング機能等もあります。） 継続的に運用していくためにはGitリポジトリへの登録やCIの設定など付随する作業が様々あります。 余談：PlaywrightでE2Eテストを書く 1. Playwrightのインストール 2.テストの実行 3.テストレポートの表示

本題

E2Eテストのコードを書いているときにいつも悩むポイント ロケーターの指定が難しい…… 悩み

Webページ上の要素を識別する方法（以下は一例） ● HTMLの属性（id属性やclass属性など） ● CSSセレクター ● XPath ※ロケーターについては以下のスライドで分かりやすく説明されています。 ロケーターを学んでテスト自動化上級者を目指そう - Speaker Deck ロケーターとは

XPathは表現力が高く、どのような要素でも取得できるので便利 XPathは便利 XPath：//*[@id="mainform"]/form/table[2]/tbody/tr[5]/td[2]/input 例）とある申込情報入力画面　［所属］のinput要素を取得する場合

以下のような困難が生じることがある ● XPathの指定自体が難しい ○ 先ほどの例のような XPathをサラッとは書けない ● 厳密なXPath表記にするとUIの変更に柔軟に対応できない ○ DOM構造が変更されるたびに要素が取得できなくなる ○ その結果、テストが失敗してしまう ○ テストが失敗するたびに XPathの修正コストがかかる XPathは便利だが…

困難を解消する手段として、data-testid属性を埋め込む ● HTMLのもつデータ属性を用いた解決方法 ● テストで利用したい要素にユニークなIDをセットする ○ E2Eテストのコードではなく、プロダクトのコードに埋め込むもの データ属性とは HTML は、特定の要素に関連付ける必要があるが、定義済みの意味を持つ必要のないデータに対する拡張性を念頭に置いて設計されています。 data-* 属性により、標準外の属性や DOM の追加プロパティなどの特殊な方法に頼らずに、標準的な意味のある HTML 要素に追加情報を格納することができ ます。 参考：データ属性の使用 - ウェブ開発を学ぶ | MDN 解決策：data-testid属性を埋め込む

例）［所属］のinput要素にdata-testid属性を埋め込む 解決策：data-testid属性を埋め込む XPath：//*[data-testid=”input-individual”]　← data-testid属性を指定するだけでよい（楽ちん）

data-testid属性を用いることで困難を解消できた ● XPathの指定自体が難しい ○ 要素に割り当てられたユニークな IDを指定するだけでよい ● 厳密なXPath表記にするとUIの変更に柔軟に対応できない ○ DOM構造に依存しづらくなり、柔軟性が向上した ○ テストの安定性が向上した data-testid属性は便利

data-testid属性そのものも懸念がないわけではない ● data-testid属性そのもののメンテナンスが増える ○ UIの実装時にdata-testid属性にユニークなIDをセットしなければならない ○ UIの変更時にdata-testid属性への影響を考慮しないといけない ● デザイン変更への適応の遅れ ○ DOM構造の変更の影響を受けない反面、その問題に気付けなくなってしまう ● セマンティクスの喪失 ○ data-testid属性はテストのためだけのもので、それ以上の意味を持たない ○ HTMLに対する意味を理解する上での助けにならない data-testid属性は便利だが…

data-testid属性そのものも懸念がないわけではないので対策が必要 ● data-testid属性そのもののメンテナンスが増える ○ 対策：命名のルールを決めておく　など ● デザイン変更への適応の遅れ ○ 対策：VRT（Visual Regression Test）を併用する　など ● セマンティクスの喪失 ○ 後述 data-testid属性は便利だが…

セマンティクス（Semantics）とは HTML要素において意味論的な意味を表現することです。 HTMLは文書構造を表現するためのマークアッ プ言語であり、セマンティクスを意識的に使用することで、文書の意味や構造が明確になり、理解しやすく なります。 セマンティクスの喪失とは data-testid属性がテスト以外の用途で使われることはありません。そのため、これではボタンが何を表しているのか、何の 機能を持っているのか、などの情報が得られません。 セマンティクスが喪失している例

セマンティクスな例 セマンティクスに依存するセレクターや属性の例 ● セマンティックなセレクター ○ タグ名やクラス名、IDなど、要素自体が持つセマンティクスに基づいたセレクター ○ buttonや.loginといったセレクターがこれに該当する

セマンティクスな例 ● aria属性 ○ アクセシビリティ向上のための WAI-ARIAの属性 ○ aria-labelやaria-labelledbyなどがあり、コンテンツの状態や性質を示す ● role属性 ○ こちらもWAI-ARIAの属性 ○ HTML要素が通常のセマンティクスを超えた役割を果たす場合に使用される ■

WAI-ARIAとは WAI-ARIAは、Web Accessibility Initiative Accessible Rich Internet Applicationsの略で、アクセシビリ ティ向上の目的で、W3Cが定めた仕様です。 WAI-ARIAをつかうことで、HTMLで表現できない意味 (セマンティック)を属性で補完することができ、スク リーンリーダーなどの支援技術を通じて、障害を持つ方に対しても適切な情報を伝えられるようになりま す。 WAI-ARIAにはコンテンツの役割を示す role属性とコンテンツの状態や性質を示す aria属性が定義されて、 role属性やaria属性を使いこなすことで、意味ない

data-testid属性そのものも懸念がないわけではないので対策が必要 ● data-testid属性そのもののメンテナンスが増える ○ 対策：命名のルールを決めておく　など ● デザイン変更への適応の遅れ ○ 対策：VRT（Visual Regression Test）を併用する　など ● セマンティクスの喪失 ○ 対策：WAI-ARIAを活用する （再掲）data-testid属性は便利だが…

● E2Eテストの要素取得の方法は様々ある ○ 要素を取得するためにプロダクトコードに手を加えることも考える ● data-testid属性はテストのためには便利 ○ テストのためだけであることを忘れない ■ 本番へのリリース時には削除するという運用もあるらしい ○ WAI-ARIAやその他セレクターをうまく使えないかを考えたうえで利用する ● WAI-ARIAを使うとプロダクトのアクセシビリティの向上にもつながる ○ 副次的にアクセシビリティに対する意識が高まりそう まとめ