なぜE2Eテストでidを使うべきではないのか

この記事は2019年に執筆されたものです。2024年にリライトした E2Eテストにおける要素選択のベストプラクティス をぜひお読みください。 こんにちは。AutifyのSET(Software Engineer in Test) 、末村(@tsueeemura)です。 皆さん、E2Eテストしてますか？以前はほぼSelenium一択みたいなところがありましたが、最近はPuppeteerやCypress、TestCafeなどいろいろなフレームワークがあり、ついつい目移りしてしまいますね！ さて、どのフレームワークを使うにせよ、E2Eテストを書く上で共通で意識しないといけない重要なファクターがいくつか存在します。 その一つが ロケータ です。操作や検証の対象となる要素を指定するためのキーのことです。 ロケータにはCSSセレクタやXPathが利用でき、idやclass、name といった属性を利用

[hiroshitoda]

以前あった類似の話とは違って、E2Eテストの観点は何であるか、他ツールのアプローチはどうであるか、メリットとデメリットは何でその中でベターな選択肢は何かが自分なりに消化・熟慮された丁寧で非常に良い内容。

[Kesin]

E2Eテストを使う人や保守する人がエンジニア的な観点が強いか、検証者的な観点が強いかによって変わると思う。しかし将来的に機械学習で人間の感覚をある程度模倣できることを考えるとidを使わない方が将来性を感じる

[el-condor]

これは実にそう。意味論的にclassが指定できるならclassでもまあいいわけだが、いずれにせよ案外難しいんだよね

[mallowlabs]

E2E テストで要素を特定するのに何を用いるべきか

[azihsoyn]

data-*属性を使うと。なるほど

[yujiorama]

テストがidやclassの変化する変更に脆くなるから専用の属性を追加したｒ、文言ベースでロケーティングする

[iga_k]

選択にはidではなく、ラベルかdata-*属性をつかう

[teppeis]

テキスト変更を検出したい場合はテキスト、そうでない場合はdata属性を使う

[rgfx]

「ここでは data-* 属性というものが推奨されており」「結局 id と data-* の二重管理に」id要素が宣言的ビューで動的生成されうる世知辛い昨今なので、E2Eテストは残された安楽の地をdata要素に求めた、という…。

[ohbarye]

“E2Eテストは外部的な振る舞い以外の何物もロックすべきではない”

[tinsep19]

デザインに関わらないロケーション用途のclassを用意していいとおもうけどね。