woshidan's blog

あいとゆうきとITと、とっておきの話。

「テストも開発もするモバイルエンジニアのためのXCUITest/Espressoのすすめ」という題でLTをしました

testautomationresearch.connpass.com

要件の細かいことを突いたりテストケースの設計が大好物だったため、そういうのを本職としているテストエンジニアはどういう人たちなのかを知りたかったので「システムテスト自動化カンファレンス2017-2」に参加してきました。

図々しく「テストも開発もするモバイルエンジニアのためのXCUITest/Espressoのすすめ」という題でLTをさせていただいたので、取りいそぎスライドとその補足についてだけでもメモします。

スライド

speakerdeck.com

スライド補足

Appiumはいろんな言語のドライバがあるので好きな言語で書けるという話について

Appiumはブログなどの件数が多いから盛り上がっているという話がありますが、各言語のドライバでQ&Aやブログ記事が割れており、また言語を特定して情報を調べないとある言語の質問について他の言語で返ってくることもあるので*1、そういう数値については3~5分の1に割り引いて考えた方が良いかと思います。

各種言語のドライバの更新状況も言語によって異なっており、たとえば

  • Rubyの最新更新は約3週間前
  • perlの最新更新はREADME.mdで1年前
  • phpの最新更新は5か月前

となっています。不具合があった時に自分でAppiumが利用している各種ツールの状況を調査するコストが取れなければ、更新頻度の少ない言語は避け、いまならCookpad, Mercariが対応すると決めているRubyのドライバを選んだ方がハマりが少ないのではないでしょうか。。

Appiumが安定していなくてつらい話

Appiumは、

  • Appiumクライアント(Appiumクライアントライブラリ=各種言語のdriver, テストスクリプト)
  • Appiumサーバ
  • uiautomator/espresso or instrument/xcuitest

といった構成になっていて*2、テストを動かすために利用しているツールが多いです。

そのせいか、気軽にバージョンアップするとどれかのツールが噛み合わなくて不安定になったり動作が非常に遅くなったりします。

Execution on iOS is extremely slow after upgrading to Appium 1.6.5 · Issue #8717 · appium/appium · GitHub

Appium 1.7.1 Automation is too slow · Issue #739 · facebook/WebDriverAgent · GitHub

前述のドライバの言語がたくさんあることと合わせて関連issueがあちこちに散っており、かつ、大量のログが貼り付けられていることも多く必要な条件が見分けにくいため、調査に時間がかかります、というか、ました。

もともとSelenium系のツールに詳しいチームで対応をとったり、安定するまで待つ*3決定をすれば問題ないかもです。

しかし、現状のEspresso/XCUITestを直接使えば、間にそれなりに大きいツールをはさまないため、その分セットアップや調査が楽でした。

上記の「手間がかかる」「楽でした」という言葉について、調べている最中も悩んでいてこの補足を書いている現在も感じることですが、自分が不勉強で手間を惜しむなんて発想をするから云々みたいなことがずっと頭の中でくるくるしています。

ですが、テストも含めてコードは必要でなくなったら捨てたいです。気軽に捨てられるためには学習コストやメンテナンスコストも含めた手間は小さいほうがよいのでは、ということも一緒にぐるぐるしています。

LTタイトルに「モバイルエンジニア」を含めていますが、自分がアプリ開発者としての環境に慣れ親しんでいるのでEspresso/XCUITestで作ったテストなら気軽に捨てられるなぁ、という感じです。

E2Eテストが全部Espresso/XCUITestでいいかという話

もともと開発者*4の自分としてはAppiumで自動テストが書きやすい範囲とEspresso/XCUITestで自動テストが書きやすい範囲が被っているように感じました。それな らば、自動化しやすい部分は動かしやすいEspresso/XCUITestを使い、サーバとの連携、プッシュ通知であったりapk/ipaの更新時の挙動など自動化しにくい部分は手動テストと組み合わせればよい、と考えていました。

とくに、専用のQAチームを置けるほど規模が大きくないチームでE2Eテストが必要な時は「手動 + Appium」より「手動 + Espresso/XCUITest」の方が楽では~くらいの勢いでした。しかし、会場に行ってみると自分が想像していた以上にリリース用apk/ipaを用いたテストを重視する雰囲気だったため、やや場違いとなりもうしわけなかったです。

ただ、それぞれのプラットフォームのツールに乗っかって開発と同じIDEでテストを書くことにすると、テスト時の動作を入ってる変数付きで再現することができます。これにより、テストが悪いか/コードが悪いかの切り分けがかなり容易になり、開発しながらテストを書くハードルもぐっと下がるのでそれだけはお伝えしたかった(誰に。

遅くなった理由

もうちょっとややこしいレイアウトやもうちょっと新しいバージョンでもう一回Espresso Test Recorderの動作確認しようかと思ったらGradle Projectのリフレッシュがなかなか終わらなくてテンパってました。はい。。

最後に運営の皆様ありがとうございました。

現場からは以上です。

*1:たとえば http://discuss.appium.io/t/how-to-close-application-between-tests/1168 . phpの質問についてRubyJavaのコードがかえってきている

*2:https://github.com/appium/appiumhttp://www.atmarkit.co.jp/ait/articles/1504/27/news025.html を元にしています

*3:このことを考えると、更新が活発な言語を選択した方が良いと思います

*4:というか今もテスト設計の方が割いてる時間が多いだけで社内の肩書きとして開発者