#UIテスト #自動テスト

ここで述べているUIの自動テスト(以降、UIテスト)の想定対象としているのは、WebアプリやiOS/Androidアプリについてです。

はじめに

プロダクトを世に出すには、何かしらのテストをおこなうことが多いと思います。
※テストとしてどのようなことを行っているかの話は面白いので別記事に書ければと思います。

特に何も考慮しないと、このテストをおこなうコストは増えやすいです。
コストが増えてくれば、そのコストを下げたいと思うことはよくあることだと思います。

そして、そのコストを下げるために、誰かしらがおこなっている(QAチームだったり、開発だったり、PMだったり色々とあります)手動テストのかわりとして、UIテストの導入を検討することもよく聞く話です。

UIテストの導入前にやるべきことがあるケースのほうが多いですが、その話については今度別記事で書くとして、今は一旦おいておきます。

ネットには、UIテストの話が色々と載っています。特にWebアプリにおいては歴史も比較的あることから色々な事例がネットなどに載っています。この手の事例を見ると、テストにかかっているコストを(簡単に)下げられるのではないか？と思ってしまいがちです。

しかし、実際はそんなに簡単にはいかないことが多いです。
UIテストを「導入するとき」「実装するとき」「運用を続けるとき」と、それぞれのフェーズにおいて色々な難しさがあります。

この難しさに対する対処をないがしろにすると、最終的にはなんとか工数をかけて実装したUIテストはあまり価値を持たずに、放置されてしまいます。

そして、消されることもなく、利用されることもなく、ただテストコードが残り続けるということがあります。
さらには、新しいメンバーが来て、残されたテストコードを動かそうとチャレンジして、諦めていくという悲しい話もあります。

UIテストは銀の弾丸ではないが、うまく扱えば良い武器になる

本記事では、自分が感じたUIテストの難しさについて色々と書いていこうと思います。
当然、全てのケースに当てはまるわけではありませんが、何かしらの参考になったら良いなと思います。

蛇足

この記事を書き始めようと思って、かつてiOS Test Nightの#1で以下のような発表をしたことを思い出しました。

ここに書いたことやWEB+DBに書いたことが、うまいこと伝わらなかったケースもありました。なのでもっと詳しく整理して書ければと思います。