はじめに
MagicPodを使ってE2Eテストを自動化してから2年ほどが経ちました。
これまでE2Eの自動テストを作成しメンテナンスしてきた中で大事だなと思ったのは以下の2点です。
- ソースコードの変更に強いテストにする
- テストの実行時間をできるだけ短くする
E2Eテストに限らず言えることだと思いますが、E2Eテストは他のテストレベルのものよりも実行コストが高く不安定になりがちなので、特に大事だと感じています。
変更に弱いテストだと、画面の見た目が変わっていないけどソースコードの内部構造が変わった場合になぜかテストが失敗することがあります。テストが失敗しやすくなるとテストの信頼性が下がったり、失敗したテストのメンテナンスにコストがかかったりしてしまいます。
また、テストの実行時間は長くなればなるほどリリースしてよいかの判断に時間がかかってしまうことになります。
ではどのようにすれば上記2点をE2Eの自動テストで実現できるのか、いくつかポイントを紹介したいと思います。
ソースコードの変更に強いロケータを使う
ロケータとは画面を構成する要素の識別子で、HTMLタグのidや、xpath、cssセレクタなどを様々なものを使うことができます。画面の構成が変更されるたびにロケータも変更しないといけない作りになっていると、テストは失敗しやすくなります。そのため、画面の構成が変更されてもロケータは変更されないような作りにするべきです。
ロケータに関してはこちらの記事がとても参考になります。
data-testid
まずは、ロケータとしてdata-testid属性を使うことが一番だと思います。要素に対して与えるテストのための属性なので、その要素がなくならない限りdata-testid属性もなくならない（変わらない）はずです。
ただ、これはソースコードにdata-testid属性を組み込まないといけません。テストケースをどう作るかだけの問題ではないので、開発者との連携が必要になります。
cssセレクタ
cssセレクタはcssの属性名が変わらない限りロケータも変わらないので、data-testidを使えない場合などにおすすめです。私たちのチームでは、基本的にcssセレクタを使うようにしています。
accessibility id
ネイティブアプリの場合は、iOSとAndroidとで共通で使えるaccessibility idもおすすめです。共通のロケータを使うことで、iOSとAndroidとで指定するロケータが同じになりテストが失敗する可能性も低くなります。
テキスト
そもそもE2Eテストの考え方として、ユーザ視点でテストをすることが重要です。そのため、ユーザが見えるテキストをロケータとして指定するのがよいとされています。
テキストも、そのテキストが指す要素の機能が変わらない限りロケータも変わらないはずです。
例えば送信ボタンのロケータのテキスト"送信"は、その送信ボタンの機能が変わる（なくなる）までテキストは基本変わりませんよね。
また、テキストを完全一致で指定するのではなくcontainsを使って指定するのもおすすめです。MagicPodではロケータを選択肢の一覧から選択することができますが、自分で自由に書くこともできます。
- テキストを完全一致で指定する
xpath=//div[text()='送信']
- テキストをcontainsで指定する
xpath=//div[contains(text(), '送信')]
実際にあったのは、ソースコードにフォーマッタをかけたらテキストにスペースが入るようになってしまい、テストケースのロケータを変更しないといけなくなる事象が発生しました。。
containsでテキストを指定すれば、上記のような場合にロケータを変更する必要はなくなります。他にも動的なテキストをロケータとして使いたい場合にも使えそうです。
「秒間待つ」を使わず「要素が表示（存在）するまで待つ」を使う
とりあえず「秒間待つ」を使うのはよくないと思っています。「秒間待つ」としてしまうと、無駄な待ち時間が発生する可能性があるからです。待ち時間が積もりに積もると、テストケースの実行時間も長くなってしまいます。
また実行時間が長くなる以外にフレーキーなテストとなってしまう場合もあります。指定した秒数待っても、様々な外部要因によりテストしたい状態になっているとは限らないからです。
単純に「秒間待つ」ことをしたい理由として考えられるのは、テストしたい画面や要素が表示されるのを待ちたいからだと思います。（外部システムの処理を待たないといけないなど外部要因もあるとは思いますが、、）
その場合に「秒間待つ」を使うのでなく、テストしたい画面の「要素が表示（存在）するまで待つ」を使うのがおすすめです。そうすれば無駄な待ち時間を削減できますし、なぜ待たないといけないか理由が分かりやすくなるという利点もあります。
おわりに
他にも、MagicPodのヘルプセンターにプラクティスがたくさん書かれています。これらを活かして自動テストを健全な状態にしていきたいですね。