Cacher is the code snippet organizer for pro developers

####idの話 テストコードでUIを操作するときにIDを指定するか、表示文言やクラスを指定することについて
#####IDで指定するメリット

• 文言は変わりやすいが役割の名称を指定するIDは変更されにくい
• 文言で指定すると同じ文言があった場合にはクラスやインデックスを指定する必要があるのでクラスxxxの文言hogeを探したりすることになるのでソー スを読むことになるかもしれない

#####デメリット

• テストコードを読むときに指定したIDが画面のどの箇所なのかわかりにくい

デメリットの方が大きいように感じる。
IDがどの箇所か探すためにviewファイルを探すことになってコードを読む時間が増えるのではないか。
とはいえ、文言指定でも同じ文言が複数使われていればクラス等を指定することになり似たような問題が発生する。
E2EテストはUI操作でユーザシナリオをテストする、という観点で考えると文言指定でいいのではないかと思う。
画面のテストをしようとすると書くコンポーネントを識別しなくてはいけないことが多い。
画面に多く配置されるコンポーネント(Twitterで言うとツイート)とかも個別に識別できるようにしないと他のユーザのツイートが存在しないことが前提のテストになりやすい気がする。

###何をexpectするかについて

• 画面上の全要素の表示・非表示を確認するか？

サービス上の重要な要素であれば確認するのはいいと思うが、全ての要素を確認するのは現実的ではないと思う。
例えば、ToDo管理サービスのユーザ管理に関するテストでログイン・ログアウトのテストをするときにタスクの表示等をexpectで確認したとしても、結局タスク管理のテストでタスクの表示やタスクへのフォーム入力等を行うので重複してしまう(入力できる=その要素は表示状態なのでexpectする必要なし、みたいな。)。
なので、そのシナリオにおけるユーザ導線に関わるものだけexpectする、という考えが良いかもしれない。